#php #mysql #codeigniter #orm
#php #mysql #codeigniter #orm
Вопрос:
У меня есть 4 таблицы, связанные следующим образом
----------- ------------ --------- ----------
| Project | | Slide | | Shape | | Points |
----------- ------------ --------- ----------
| id | | id | | id | | id |
----------- | project_id | |slide_id | | shape_id |
------------ --------- | x |
| y |
----------
Из документов ORM, которые я читал для объекта Active record, встроенного в CodeIgniter, лучше всего сохранить структуру таблиц таким образом или изменить их одним из следующих способов.
Во-первых, было бы использовать общую реляционную таблицу, подобную этой
----------- ------------ --------- ---------- -------------------------------
| Projects | | Slides | | Shapes | | Points | | Projects_Slides_Shapes_Points |
----------- ------------ --------- ---------- -------------------------------
| id | | id | | id | | id | | id |
----------- ------------ --------- | x | | Project_id |
| y | | Slide_id |
---------- | Shape_id |
| Point_id )
-------------------------------
Таким образом, все связано одной таблицей или я должен связать вещи с отдельными таблицами, чтобы вместо приведенных выше таблиц отношений выглядели следующим образом.
----------------- --------------- ---------------
| Projects_Slides | | Slides_Shapes | | Shapes_Points |
----------------- --------------- ---------------
| id | | id | | id |
| Project_id | | Slide_id | | Shape_id |
| Slide_id | | Shape_id | | Point_id |
----------------- --------------- ---------------
Первый способ будет иметь меньшее количество записей, но меньше запросов для построения объекта ORM, с другой стороны, у другого меньше записей и больше запросов. Я действительно не знаю, что лучше или что предпочитает ORM. Или если ORM может обрабатывать одно или другое.
Или для ORM могу ли я оставить их такими, какие они есть, и я неправильно понимаю документы.
Спасибо за совет.
Комментарии:
1. На что ссылается ‘cont_id’ в таблице ‘Shape’?
2. Да, отредактировано, чтобы иметь смысл, извините за это.
Ответ №1:
Сначала вы должны определить, какие отношения вы собираетесь установить между четырьмя различными объектами, которые вы определили.
Например, нет необходимости создавать таблицу «Projects_Slides», если у вас нет отношения «многие ко многим» между «Проектом» и «Слайдами». Как бы то ни было, я предполагаю, что вы хотели бы, чтобы в каждом проекте было много слайдов, и каждый слайд был связан только с одним проектом? В этом случае у вас есть отношение «один ко многим», и первая схема была бы лучшей.
Если бы вы определили, что слайд может принадлежать более чем одному проекту, тогда это было бы отношением «многие ко многим», и таблица «Projects_Slides» имела бы смысл.
Комментарии:
1. Все таблицы имеют отношение «один ко многим», поэтому для project -> slide -> shape -> points, его project (one) -> slide (many), slide (one) -> shape (many), shape (one) -> points (many)
2. В этом случае я бы использовал первую схему.
3. Итак, с этой структурой я не могу понять, как использовать ORM, если вы не возражаете привести пример. ORM, который я использую, встроен в codeigniter, но я не собираюсь использовать какие-либо рекомендуемые.
4. Я раньше не использовал Codeigniter, но из документации по адресу: codeigniter.com/wiki/ActiveRecord_Class . Чтобы получить все слайды для проекта, вы должны использовать $project = $this-> Project->find_by_id(1); $projectSlides = $project->fetch_related_slides();
Ответ №2:
Предполагалось ли, что таблица Shapes будет содержать ссылки на себя (в ней есть столбцы id и shape_id)?
Как правило, ORM наиболее удобны, когда вы должным образом нормализуете свою базу данных. Я бы сказал, что ваш первый пример наиболее правильно нормализован, если вы пытаетесь делать то, что я думаю, что вы делаете.
Комментарии:
1. Я отредактировал это, извините, у меня, наверное, немного сдох мозг. Какой была бы нормализованная база данных для проекта, который содержит набор слайдов, содержащих набор фигур, содержащих набор точек?
2. Первый набор таблиц в верхней части является наиболее правильно нормализованным для вашего случая вложенных отношений «один ко многим». Я бы выбрал эту структуру. Другие являются довольно запутанными и в некоторых случаях могут быть необходимы для оптимизации производительности, но обычно нормализованная база данных работает лучше с большинством фреймворков ORM.