Форум программистов
 
Контакты: о проблемах с регистрацией, почтой и по другим вопросам пишите сюда - alarforum@yandex.ru, проверяйте папку спам! Обязательно пройдите активизацию e-mail.

Вернуться   Форум программистов > Web > SQL, базы данных
Регистрация

Восстановить пароль
Повторная активизация e-mail

Ответ
 
Опции темы
Старый 08.02.2018, 10:51   #1
Андрей Цапко
Форумчанин
 
Регистрация: 10.04.2017
Сообщений: 66
Репутация: 10
По умолчанию Одна большая таблица или много маленьких

Здравствуйте. Стоит следующая задача: сделать переписки между пользователями. Для дополнительного функционала, в БД записи о сообщениях хранятся дважды. Одна для отправителя, другая для получателя. В записи есть ссылка на само сообщение. Есть ли смысл хранить сообщения всех пользователей в одной таблице и использовать поля id и type для поиска сообщений конкретного пользователя или лучше для каждого пользователя отвести отдельную таблицу вида name_type_id и там уже хранить все данные. По идеи отпадет поиск по 2-м условиям и просто будут запросы в конкретную таблицу. Выгодно ли это?
P.S. Пока что это все делается на mysql, но позже перейдет на postgresql.
Андрей Цапко вне форума   Ответить с цитированием
Старый 08.02.2018, 11:02   #2
Аватар
Модератор
Заслуженный модератор
 
Аватар для Аватар
 
Регистрация: 17.11.2010
Адрес: Северодонецк.ua
Сообщений: 18,095
Репутация: 6385
По умолчанию

А если юзеров тысяча, то и таблиц столько? Конечно в одной. И что за функционал, требующий дублирование записей?
__________________
Если бы архитекторы строили здания так, как программисты пишут программы, то первый залетевший дятел разрушил бы цивилизацию
Аватар вне форума   Ответить с цитированием
Старый 08.02.2018, 13:16   #3
Андрей Цапко
Форумчанин
 
Регистрация: 10.04.2017
Сообщений: 66
Репутация: 10
По умолчанию

юзеров может быть и миллион и 2 и 10. система должна быть готова на все. Дублирование записей нужно, что бы, например, в беседе когда 1 пользователь прочитает сообщение у других оно отображалось как не прочитанное, или что бы можно было ставить пометки к сообщениям (избранное, важное), и соответственно у одного пользователя она может стоять, а у другого её не будет, а пользователей в переписке может быть не ограниченное количество.
Андрей Цапко вне форума   Ответить с цитированием
Старый 08.02.2018, 13:39   #4
ADSoft
Профессионал
 
Регистрация: 25.02.2007
Адрес: Татарстан
Сообщений: 3,272
Репутация: 912

icq: 303-206-418
skype: ad-soft.info
По умолчанию

бред...
мечты о миллионе пользователей - для вк, фейсбука и иже .... никто из разработчиков такого уровня не спрашивал бы советов тут ))))

По существу: всех пользователей хранить в одной таблице, если у вас будет 100500 таблиц для пользователей - зае...сь запросы писать что где откуда.....

Дубли так же не нужны.... зачем? сообщение то по факту одно, а вот для изменения статусов прочитанности сообщений - нужно просто доп табличку завести, и там по ид сообщения и ид пользователя отмечать кто прочел, когда прочел итд
ADSoft вне форума   Ответить с цитированием
Старый 08.02.2018, 23:24   #5
Андрей Цапко
Форумчанин
 
Регистрация: 10.04.2017
Сообщений: 66
Репутация: 10
По умолчанию

Цитата:
Сообщение от ADSoft Посмотреть сообщение
бред...
мечты о миллионе пользователей - для вк, фейсбука и иже .... никто из разработчиков такого уровня не спрашивал бы советов тут ))))

По существу: всех пользователей хранить в одной таблице, если у вас будет 100500 таблиц для пользователей - зае...сь запросы писать что где откуда.....

Дубли так же не нужны.... зачем? сообщение то по факту одно, а вот для изменения статусов прочитанности сообщений - нужно просто доп табличку завести, и там по ид сообщения и ид пользователя отмечать кто прочел, когда прочел итд
На счет мечты о миллионе пользователей... Извините, конечно, но это для вас должно быть не важно. Мне необходимо выдержать любую возложенную на СУБД нагрузку. На счет дублирования... Возможно вы не поняли что я хотел сделать. Есть таблица с пользователями. Точнее их 3, для разных типов пользователей, возможно будет больше. Есть таблица со списками бесед (на примере вк это те чаты которые отображаются слева на странице сообщений) там информация о последнем сообщении, кол-ве не прочитанных сообщений и прочая другая более часто требуемая информация. Есть таблица, собственно, сообщений.

Таблица с информацией о, как вы сказали статусе прочитанной или помеченной, сейчас содержит записи кому принадлежит запись (тип и номер), по которым ищутся необходимые записи для конкретного чата и ссылку на само сообщение (то что отправлено, текст, файлы и прочая информация (дата и тд)).

Я хочу разделить таблицу из этой общей таблицы с таким же названием, но с приписками в конце указывающими тип и номер пользователя. Так мне не надо будет искать эту информацию при выборке и при INSERT-е (а их будет много) одна операцию не будет ждать другую, по крайней мере редко. INSERT вызывает блокировку на уровне таблицы, на сколько мне известно, а если таблиц будет много, то я могу переместить некоторые данные из поиска в поле имени.

Вопрос лишь в том, поможет ли мне это ускорить работу СУБД или нет?
Андрей Цапко вне форума   Ответить с цитированием
Старый 09.02.2018, 09:03   #6
ADSoft
Профессионал
 
Регистрация: 25.02.2007
Адрес: Татарстан
Сообщений: 3,272
Репутация: 912

icq: 303-206-418
skype: ad-soft.info
По умолчанию

Цитата:
Вопрос лишь в том, поможет ли мне это ускорить работу СУБД или нет?
чего-то сомневаюсь, в любом случае нужно не "сферического коня в вакууме" рассматривать а смотреть уже структуру таблиц, взаимосвязи, индексы и прочее.

Вот просто для интереса - пусть все пользователи раскиданы по таблицам... приведите пример SQL запроса, который будет показывать чат, ну например 3 пользователей??? а если 100? А если их число в принципе не известно?

ИМХО - разделение таблиц по принципу пользователей не встречал.... насчет блокировки на уровне таблицы - тоже сомнения - там блокировка на уровне конкретной строки
ADSoft вне форума   Ответить с цитированием
Старый 09.02.2018, 11:08   #7
Serge_Bliznykov
МегаМодератор
СуперМодератор
 
Регистрация: 09.01.2008
Сообщений: 24,614
Репутация: 5352
По умолчанию

Цитата:
Сообщение от Андрей Цапко Посмотреть сообщение
Есть таблица с пользователями. Точнее их 3, для разных типов пользователей, возможно будет больше.
ересь, одна таблица пользователь более чем достаточна. все типы пользователей - это просто дополнительное поле в таблице.


Цитата:
Сообщение от Андрей Цапко Посмотреть сообщение
там информация о последнем сообщении, кол-ве не прочитанных сообщений и прочая другая более часто требуемая информация.
это вообще не нужно хранить. эта информация элементарно получается запросами - и сколько всего сообщений у пользователя и сколько из них прочитанных, сколько непрочитанных и т.д. и т.п.


Цитата:
Сообщение от ADSoft Посмотреть сообщение
насчет блокировки на уровне таблицы
сильно зависит от СУБД. но, скорее всего, таблица действительно блокируется на время операции, но блокируется на запись. Чтение доступно.

решать это можно (если это реально нужно) через вставку в промежуточную(ые) таблицу(ы), из которой данные периодически копируются в основную.
Но, в связи с тем, что обычная СУБД легко обрабатывает несколько тысяч операций INSERT в секунду, не думаю, что проблема возникнет раньше, чем число пользователей превысит сотни тысяч (сколько нужно пользователей, чтобы в каждую секунду несколько тысяч одновременно выполняло INSERT? Сам сервер раньше ляжет под такой нагрузкой, чем СУБД).
Преждевременная оптимизация обычно избыточна.

p.s. идея с разделением таблиц по пользователям очень плохая. Так делать нельзя.
Вообще, при разработке структуры БД, если возникает необходимость изменять структуру во время работы, значит, это на 99% хреновая организация БД.
Тут тот самый вариант. Я бы категорически не рекомендовал Вам так делать.
Serge_Bliznykov вне форума   Ответить с цитированием
Старый 09.02.2018, 14:58   #8
Андрей Цапко
Форумчанин
 
Регистрация: 10.04.2017
Сообщений: 66
Репутация: 10
По умолчанию

Цитата:
Сообщение от Serge_Bliznykov Посмотреть сообщение
ересь, одна таблица пользователь более чем достаточна. все типы пользователей - это просто дополнительное поле в таблице.
В этих таблицах могут храниться адреса страниц на сайте (для разных типов пользователей отдельные адресные пространства), а ключ у поля адреса уникальный. Да и в целом каждый тип пользователя обладает совершенно разным набором информации и я заранее знаю какой тип пользователя мне нужен и соответственно переберается меньше записей в бд при поиске не по первичному ключу. В добавок есть уникальное поле почты, а на одну почту можно зарегестрироваться 2 раза под разными видом (физ. лицо, юр. лицо)

Цитата:
p.s. идея с разделением таблиц по пользователям очень плохая. Так делать нельзя.
Вообще, при разработке структуры БД, если возникает необходимость изменять структуру во время работы, значит, это на 99% хреновая организация БД.
Тут тот самый вариант. Я бы категорически не рекомендовал Вам так делать.
В целом я вас понял, но тогда мне надо добавлять индексы для поиска. На сколько я знаю, много индексов не хорошо сказываются на добавлении, а в индексы нужно указывать критерии по которым ведется поиск
Андрей Цапко вне форума   Ответить с цитированием
Старый 09.02.2018, 15:01   #9
Андрей Цапко
Форумчанин
 
Регистрация: 10.04.2017
Сообщений: 66
Репутация: 10
По умолчанию

Цитата:
Сообщение от ADSoft Посмотреть сообщение
Вот просто для интереса - пусть все пользователи раскиданы по таблицам... приведите пример SQL запроса, который будет показывать чат, ну например 3 пользователей??? а если 100? А если их число в принципе не известно?
Не много не понял вопроса. Пользователь с типом 1 и номером 2345345 запрашивает чат(не важно с каким пользователем). Запрос следующий "SELECT * FROM `messages-user-1-2345345` WHERE ...."
Андрей Цапко вне форума   Ответить с цитированием
Старый 09.02.2018, 16:06   #10
ADSoft
Профессионал
 
Регистрация: 25.02.2007
Адрес: Татарстан
Сообщений: 3,272
Репутация: 912

icq: 303-206-418
skype: ad-soft.info
По умолчанию

вы вообще все данные которые полагаются тому или иному юзеру собираетесь хранить в таблице данного юзера?
А вы точно хотите работать с реляционными БД????
если у вас планируется все плоско и минимальными связями - посмотрите в сторону NoSQL БД? может посмотреть в сторону Redis и иже?

а в целом мне кажется что вы совершенно неверно сейчас пытаетесь спланировать структуру БД...

все что вы описали выше - свои наборы полей, страниц и прочее - все отлично через связанные таблицы реализуется
ADSoft вне форума   Ответить с цитированием
Ответ

Опции темы

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход

Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
(MVC)Много пользователей - одна модель Sasha811 ASP.NET 1 27.12.2015 15:57
Большая сводная таблица! Hafling Microsoft Office Access 0 19.03.2014 18:03
Одна команды-много данных на mmx y0rker Assembler 0 25.06.2012 16:48
Много таблиц или одна таблица? RuVarez SQL, базы данных 7 19.05.2012 22:00
Одна большая таблица или много маленьких. SlvUn Microsoft Office Access 2 20.11.2009 21:15


04:15.


Powered by vBulletin® Version 3.8.8 Beta 2
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.

RusProfile.ru


Справочник российских юридических лиц и организаций.
Проекты отопления, пеллетные котлы, бойлеры, радиаторы
интернет магазин respective.ru