|
|
Регистрация Восстановить пароль |
Повторная активизация e-mail |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
|
Опции темы | Поиск в этой теме |
08.02.2018, 09:51 | #1 |
Пользователь
Регистрация: 10.04.2017
Сообщений: 66
|
Одна большая таблица или много маленьких
Здравствуйте. Стоит следующая задача: сделать переписки между пользователями. Для дополнительного функционала, в БД записи о сообщениях хранятся дважды. Одна для отправителя, другая для получателя. В записи есть ссылка на само сообщение. Есть ли смысл хранить сообщения всех пользователей в одной таблице и использовать поля id и type для поиска сообщений конкретного пользователя или лучше для каждого пользователя отвести отдельную таблицу вида name_type_id и там уже хранить все данные. По идеи отпадет поиск по 2-м условиям и просто будут запросы в конкретную таблицу. Выгодно ли это?
P.S. Пока что это все делается на mysql, но позже перейдет на postgresql. |
08.02.2018, 10:02 | #2 |
Старожил
Регистрация: 17.11.2010
Сообщений: 18,922
|
А если юзеров тысяча, то и таблиц столько? Конечно в одной. И что за функционал, требующий дублирование записей?
Если бы архитекторы строили здания так, как программисты пишут программы, то первый залетевший дятел разрушил бы цивилизацию
|
08.02.2018, 12:16 | #3 |
Пользователь
Регистрация: 10.04.2017
Сообщений: 66
|
юзеров может быть и миллион и 2 и 10. система должна быть готова на все. Дублирование записей нужно, что бы, например, в беседе когда 1 пользователь прочитает сообщение у других оно отображалось как не прочитанное, или что бы можно было ставить пометки к сообщениям (избранное, важное), и соответственно у одного пользователя она может стоять, а у другого её не будет, а пользователей в переписке может быть не ограниченное количество.
|
08.02.2018, 12:39 | #4 |
Старожил
Регистрация: 25.02.2007
Сообщений: 4,160
|
бред...
мечты о миллионе пользователей - для вк, фейсбука и иже .... никто из разработчиков такого уровня не спрашивал бы советов тут )))) По существу: всех пользователей хранить в одной таблице, если у вас будет 100500 таблиц для пользователей - зае...сь запросы писать что где откуда..... Дубли так же не нужны.... зачем? сообщение то по факту одно, а вот для изменения статусов прочитанности сообщений - нужно просто доп табличку завести, и там по ид сообщения и ид пользователя отмечать кто прочел, когда прочел итд |
08.02.2018, 22:24 | #5 | |
Пользователь
Регистрация: 10.04.2017
Сообщений: 66
|
Цитата:
Таблица с информацией о, как вы сказали статусе прочитанной или помеченной, сейчас содержит записи кому принадлежит запись (тип и номер), по которым ищутся необходимые записи для конкретного чата и ссылку на само сообщение (то что отправлено, текст, файлы и прочая информация (дата и тд)). Я хочу разделить таблицу из этой общей таблицы с таким же названием, но с приписками в конце указывающими тип и номер пользователя. Так мне не надо будет искать эту информацию при выборке и при INSERT-е (а их будет много) одна операцию не будет ждать другую, по крайней мере редко. INSERT вызывает блокировку на уровне таблицы, на сколько мне известно, а если таблиц будет много, то я могу переместить некоторые данные из поиска в поле имени. Вопрос лишь в том, поможет ли мне это ускорить работу СУБД или нет? |
|
09.02.2018, 08:03 | #6 | |
Старожил
Регистрация: 25.02.2007
Сообщений: 4,160
|
Цитата:
Вот просто для интереса - пусть все пользователи раскиданы по таблицам... приведите пример SQL запроса, который будет показывать чат, ну например 3 пользователей??? а если 100? А если их число в принципе не известно? ИМХО - разделение таблиц по принципу пользователей не встречал.... насчет блокировки на уровне таблицы - тоже сомнения - там блокировка на уровне конкретной строки |
|
09.02.2018, 10:08 | #7 | ||
Старожил
Регистрация: 09.01.2008
Сообщений: 26,229
|
Цитата:
Цитата:
сильно зависит от СУБД. но, скорее всего, таблица действительно блокируется на время операции, но блокируется на запись. Чтение доступно. решать это можно (если это реально нужно) через вставку в промежуточную(ые) таблицу(ы), из которой данные периодически копируются в основную. Но, в связи с тем, что обычная СУБД легко обрабатывает несколько тысяч операций INSERT в секунду, не думаю, что проблема возникнет раньше, чем число пользователей превысит сотни тысяч (сколько нужно пользователей, чтобы в каждую секунду несколько тысяч одновременно выполняло INSERT? Сам сервер раньше ляжет под такой нагрузкой, чем СУБД). Преждевременная оптимизация обычно избыточна. p.s. идея с разделением таблиц по пользователям очень плохая. Так делать нельзя. Вообще, при разработке структуры БД, если возникает необходимость изменять структуру во время работы, значит, это на 99% хреновая организация БД. Тут тот самый вариант. Я бы категорически не рекомендовал Вам так делать. |
||
09.02.2018, 13:58 | #8 | ||
Пользователь
Регистрация: 10.04.2017
Сообщений: 66
|
Цитата:
Цитата:
|
||
09.02.2018, 14:01 | #9 |
Пользователь
Регистрация: 10.04.2017
Сообщений: 66
|
Не много не понял вопроса. Пользователь с типом 1 и номером 2345345 запрашивает чат(не важно с каким пользователем). Запрос следующий "SELECT * FROM `messages-user-1-2345345` WHERE ...."
|
09.02.2018, 15:06 | #10 |
Старожил
Регистрация: 25.02.2007
Сообщений: 4,160
|
вы вообще все данные которые полагаются тому или иному юзеру собираетесь хранить в таблице данного юзера?
А вы точно хотите работать с реляционными БД???? если у вас планируется все плоско и минимальными связями - посмотрите в сторону NoSQL БД? может посмотреть в сторону Redis и иже? а в целом мне кажется что вы совершенно неверно сейчас пытаетесь спланировать структуру БД... все что вы описали выше - свои наборы полей, страниц и прочее - все отлично через связанные таблицы реализуется |
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
(MVC)Много пользователей - одна модель | Sasha811 | ASP.NET | 1 | 27.12.2015 14:57 |
Большая сводная таблица! | Hafling | Microsoft Office Access | 0 | 19.03.2014 18:03 |
Одна команды-много данных на mmx | y0rker | Assembler - Ассемблер (FASM, MASM, WASM, NASM, GoASM, Gas, RosAsm, HLA) и не рекомендуем TASM | 0 | 25.06.2012 16:48 |
Много таблиц или одна таблица? | RuVarez | SQL, базы данных | 7 | 19.05.2012 22:00 |
Одна большая таблица или много маленьких. | SlvUn | Microsoft Office Access | 2 | 20.11.2009 20:15 |