Как в mysql целостно связать таблицы под каждый тип поля ?

В общем, в бд есть сущность, ее можно наделять полями, соответственно поля могут быть разных типов text,datetime,int и тд.
Решил что под каждый тип поля - нужна своя таблица, типа type_string, type_int и т.д.
Но никак не могу придумать как можно связать эти таблицы с сущностью по внешним ключам, чтобы сохранилась целостность. Как определить какую таблицу JOIN'ить зная тип поля?
Знаю такой подход точно используется в некоторых CMS (shopscript, hostcms), но так и не разобрался, они выбор таблиц делали на уровне логики или там какая-то хитрая реляционная модель..
  • Вопрос задан
  • 2525 просмотров
Решения вопроса 1
go3l337
@go3l337 Автор вопроса
Так как значение у поля по большому счету либо int, либо text или datetime, то решил сделать так:
в таблице с полями делаем id поля и тип, а в таблице значений полей делаем 4 поля: id сущности, id поля, значение для строк, значение для int. Таким образом, в зависимости от типа поля берем значение из int или из text. Думаю это не самое правильное решение, но достаточно простое.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
@brutal_lobster
Что-то подсказывает, вы несколько усложняете свою архитектуру.
Для чего вам необходимы свои таблицы под каждое свойство?

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

Выносите это в приложение или обратите внимание на nosql решение.
Можете сделать таблицу свойств сущностей, с типом свойства и его значением в виде json, например.
Ответ написан
Serhioromano
@Serhioromano
Web Developer
Я полагаю вы делаете что то вроде CCK.

Есть 2 подхода как хранить такие архитектуры.

Вертикальный

Это то о чем вы написали. Вы хнарите поля как строки в таблице полей. Для этого вам нужно 2 таблици. Одна это тип. Другая это поля. Где в таблице поля будет ссылка на тип. Таким образом вы всегда можете выбрать список полей этого типа как для построения формы, так и для отображения данных.

Нужна будет еще одна таблица для хранения статей и данных полей этой статьи. Это как бы связь между типом и статей на его основе. И уже в таблице хранения данных полей, можно использовать разные колонки для разных типов.

Хотя я использовал один тип и это достаточно быстро работает до 100 000 записей в разделе. Но если больше то надо конечно свои типы определять.

Естественно каждое поле это РНР класс или на чем вы там пришите. И просто у него есть свойство типа данных. На основе этого свойства и знаешь что дергать.

Горизонтальный

Это когда вы создаете таблицу под каждый тип и добавляете поля в эту таблицу как колонки. Тут можно обойтись одной таблицей.

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

Есть еще свои подводные камни. Я делал CCK для CMS использую вертикальный подход. И пока что не пожалел.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы