бамп
бамп
бамп
бамп
message_id dialog_id message_text
бамп
Получается, я должен перебирать всю таблицу со всеми сообщениями всех пользователей чтобы найти сообщения конкретного диалога?
JS ретардиньо, зачем ты сюда высираться пришел?
Я всегда тута спрашиваю советов
Господи, вкатыш куда ты лезешь нахуй? Изучи что такое индексы и как они работают для начала. А лучше найди нормальную профессию, сантехник например
Для тебя есть slq query, дебил
>Изучи что такое индексы и как они работают для начала
А что это такое и как они работают?
Какие ему индексы, он элементарно не имеет представления об sql запросах
Що такое, какие query?
Здесь ты услышишь лишь советы вкатунов-неудачников.
Адекваты тут не сидят.
Ловите вкатуна !!!
Открой книгу по реляционным бд и начни хотя бы с самого элементарного - нормальных форм.
> мне придется сваливать все сообщения от всех пользователей в одну таблицу
Да.
Кристофер Дейт
Введение в системы баз данных
Томас Коннели
Database Systems: A Practical Approach to Design, Implementation, and Management
Мартин Фаулер
NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence
Теория нормализации.
А какую книжку лучше открыть?
В твоём случае букварь
Долбоеб, нахуя ты лезешь в бэк, занимайся своим формошлепством
0, 1, 2, 3... и т.д., автоматически увеличиваются на 1 и являются уникальными.
А вообще про сантехника подумой.
мимо не айтишник и даже не вкатывальщик
Поржал с опа
senior HTML developer 250k/month
senior HTML developer 250k/month
В контексте sql это не верно.
250к членов в месяц жмёшь?
Давно ходил с CSS lead девелопером на пив
>сантехника подумой
Сантехником быть еще труднее чем программистом, там требуется хотя бы средний интеллект
Это автоинкремент. Если этот даун реально собрался десятки миллионов сообщений хранить в чем я сомневаюсь, всё закончится на том что он напишет hello world сам себе, увидит кучу ошибок, пукнет и обмякнет то надо как минимум составной индекс dialog_id + message_id, тогда уже придется перебирать не десятки миллионов сообщений, а просто кол-во диалогов и потом уже искать сообщение. Будет очень быстро. Если еще быстрее надо, то там уже костыли пойдут всякие.
>реляционным бд
Хранить ветки сообщений в реляционной базе данных? Ты идиот чтоли. Это чистый NoSQL
Ну меня тогда бы в айти ждал неминуемый успех, т.к. я инженер.
Но как уже писал я не айтишник.
Долбоеб твоя вотчина это формошлепство
> или как-то можно их разделить?
Можешь по гео сервера бд раскидать.
Ему надо расчехлять биг дик дату, редис, редукс или что там для этого используют. Иначе ответ будет дольше чем у лежащего дискорда от бд.
>минимум составной индекс dialog_id + message_id
Guid?
А я разве написал что реляционные бд пригодны в случае опа ?
ты даун?
ты посоветовал в его случае хуйню. Пускай открывает что-то типа "7 баз данных за 7 недель", чтобы посмотреть какие вообще БД есть и для чего используются. Твой совет не позволяет решить его задачу, потому что охватывать будет только реляционные
>Инженер
>Возомнил себя выше сантехника
Ты хоть трубы видел?
Про инженеров по гидравлике слышал?
MongoDB посмотри, с её помощью можно организовать хранение. Пользователей в MySQL/PostresQL, диалоги в MongoDB
Сделай большой массив в ноде и храни там. Это самое быстрое что только возможно в твоем случае
Блядь, а может лучше на вкатываться, ты задумайся
Как много токсичных пирожков порвалось
Ух бля какой ты душный, хабраблядь дотошная
Хуле ты приебался ? А ? А ?
Я не пытался решить его проблему, мне абсолютно похуй научится он чему-то или нет. Вопрос был по sql бд, я ему так и ответил
>7 баз данных за 7 недель
Спасибо, анончик, буду изучать
Абу благословил этот пост.
Снежинка нетоксичная, уже клеточку на на ключ на своём хуе заперла?
отдельно беседы
отдельно сообщения
по айди бесед джойнишь
отдельно сообщения
по айди бесед джойнишь
Это только для малых нагрузок подходит, с ростом числа сообщений такой подход довольно быстро захлебнется.
А с высоконагруженными как поступают?
Ничего не захлебнётся. Достаточно правильно организовать индексы и забирать не всё сразу, а с LIMIT и OFFSET.
А вообще хранить переписку на удалённом сервере в нынешних реалиях - моветон. Сохраняй локально (SQLite), предварительно зашифровав. Там как раз будут связи между контактами у определённого юзера.
Пиздец нахуй, откуда вы лезете?
Уже писали выше про NoSQL-хранилища.
ПАМАГИТЕ!!!
Как хранить сообщения для каждого из диалогов, ожидается, что сообщений будет много и диалогов будет много, мне придется сваливать все сообщения от всех пользователей в одну таблицу или как-то можно их разделить?