NK
можно хранить свойства одного объекта в разных таблицах, но это, имхо, нужно только в больших и сложных системах, где у разных объектов есть одни и те же свойства
Size: a a a
2016 December 18
NK
я с таким сталкивался на авиапроизводстве
R
не обязательно, обычно 1 объект - не 1 таблица, это только упрощенный вариант
R
есть есть has_one, has_many - то это минимум 2
NK
правильно ли я понимаю, что если мы создали сущность (например, Clients, или Barbers), то данные, которые относятся к экземплярам этой сущности могут храниться в разных таблицах?
R
скажем так: простые свойства (имя, телефон) будут храниться в 1 таблице. Как только ты делаешь сложные свойства - например барбер работает в каком-то барбершопе. То вот инфа о барбершопе хранится в другой таблице.
R
т.е. ты говоришь barber.barbershop.address
R
получается, что обращаешься к barber, а адрес барбершопа считывается из другой таблицы
R
но бывает и т.н. денормализация - когда данные о двух сущностях хранятся в 1 таблице
R
обычно эти сущности схожи
NK
а что мешает запилить одну большую таблицу и хранить там вообще всё, что относится к сущности barbers?
NK
или если надо что-то добавить, то делать миграцию с изменением количества столбцов?
R
теоретически такое возможно
R
на практике такое не делают, т.к. чем больше таблица - тем меньше скорость ее чтения
R
ну и мешать все в одно - как-то геморно, потом не поймешь что к чему относится
NK
мне кажется наоборот, можно запутаться в выискивании связей между таблицами и определении, каким sql-запросом что вытягивается
R
еще подумай об индексах - индексация помогает быстрее искать по таблице. Но ты за это платишь обычно местом на диске (и/или в памяти). Чем больше индексировано полей в 1 таблице, тем больше требуется памяти на обработку данных в этой таблице. Тут уже как бы вопрос ограничений БД
NK
походу дела, надо брать книгу по теории баз данных
NK
и курить е
ё
ё
NK
её