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

 В общем, в бд есть сущность, ее можно наделять полями, соответственно поля могут быть разных типов text,datetime,int и тд.  

Решил что под каждый тип поля - нужна своя таблица, типа type\_string, type\_int и т.д.   

Но никак не могу придумать как можно связать эти таблицы с сущностью по внешним ключам, чтобы сохранилась целостность. Как определить какую таблицу JOIN'ить зная тип поля?  

Знаю такой подход точно используется в некоторых CMS (shopscript, hostcms), но так и не разобрался, они выбор таблиц делали на уровне логики или там какая-то хитрая реляционная модель.. 

 Так как значение у поля по большому счету либо int, либо text или datetime, то решил сделать так:  

в таблице с полями делаем id поля и тип, а в таблице значений полей делаем 4 поля: id сущности, id поля, значение для строк, значение для int. Таким образом, в зависимости от типа поля берем значение из int или из text. Думаю это не самое правильное решение, но достаточно простое. 

 Что-то подсказывает, вы несколько усложняете свою архитектуру.   

Для чего вам необходимы свои таблицы под каждое свойство?   
  

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

(ну, скорее всего можно придумать что-нибудь работающее с триггерами и процедурами - но по-моему это будет страшно и не сопровождаемо)  
  

Выносите это в приложение или обратите внимание на nosql решение.   

Можете сделать таблицу свойств сущностей, с типом свойства и его значением в виде json, например. 

 Я полагаю вы делаете что то вроде CCK.  
  

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

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

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

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

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

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

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

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