в таком случае: у вас есть чаты, они делятся на два типа: диалоги(два человека) и группы(много людей), базовые ключи у них одинаковые(имя, дата создания, участники и т.д.), но у группы может быть больше колонок (роли участников, иконка группы и т.д.), вы бы разделили это все дело на две таблицы(группы, диалоги) или сделали одну (чаты)?
красивее будет конечно разделить тогда управление будет легче
Разделить. И скорее всего отдельно завести сущность которая содержит и тех и других, чтобы было откуда полный список брать. Всё что можно разделить - всегда лучше разделить, если на это есть ресурсы разработки.
Еще вопрос, получается делать два запроса на получение из той и из той таблицы, чтоб получить все чаты хуже, чем создать третью, в которой будут все?
В зависимости от того какие операции у тебя происходят чаще и насколько тебе дорого место на дисках. Место на дисках я считаю практически бесплатным, в сравнении со стоимостью ресурсов процессора (которые обычно нельзя просто добавить, т.к. встаёт вопрос шардирования). Обычно список чатов смотрят чаще, чем меняют. И список чатов обычно смотрят в отсортированном порядке. Именно так можно и хранить его в отдельной табличке. Если же делать запрос из двух табличек, то ты не сможешь сделать сортировку по индексу.
Думал про это, можно было бы добавить какую-то колонку типа order_number, но это уже похоже на затычку, причем довольно страшную
А толку? - Вот у тебя две таблицы. В них есть order number. Ты по ним отсортировал данные. И тебе нужно объединить результаты с учётом сортировки, это не по индексу будет опять же =) Лучше отдельная табличка, имхо.
Сорян, забыл спросить, последний вопрос, есть какая-то особая технология для создания смежной табл. или она как обычная табл.? Просто закидывать в нее данные когда эдитишь первые две?
По юзерам many_to_many? users_chats - что-то типо этого?
Как уже много раз повторяли - всё зависит от того как вы с этим работаете. Для типичного чата, скорее всего, это будет хорошее решение.
А почему это будет не по индексу? При чём-то вроде CREATE VIEW all_chats AS SELECT ... FROM table1 UNION ALL SELECT ... FROM table2 запрос вроде SELECT * FROM all_chats WHERE user_id = $1 ORDER BY chat_name вполне себе будет использовать индексы (если они есть) как для выборки, так и для сортировки, нет? Или речь о какой-то другой ситуации?
VIEW - плохое решение для чатов, имхо.
View здесь для демонстрации (записать его текст в запрос как WITH или подзапрос — и будет то же самое). Почему view — плохое решение, кстати?
Уже поздно наверное, но спрошу, а какое решение в данном случае предлагаешь ты? У меня просто orm не поддерживает полиморфные связи)
Так я же не знаю, какие точно требования... особенно с учётом "неестественных" ограничений вроде: > У меня просто orm не поддерживает полиморфные связи)
Обсуждают сегодня