Есть таблица CLIENTS в которой для универсальности не стал создавать поля NAME, SURNAME, B_DATE и др. а решил использовать механизм с помощью которого можно будет задавать такие поля для программы при внедрение у клиентов. Таблица CLIENT_PROPS_LIST – содержит список таких полей, а при создание клиента заполняется CLIENTS_PROPS на базе полей заложенных в CLIENT_PROPS_LIST
Insert into CLIENTS_PROPS
Select from CLIENTS_PROPS_LIST
Вопрос в том какого типа надо создавать поле VALUE в таблице CLIENTS_PROPS(в которой уже для каждого клиента будет значение соответствующего поля). Использовать VARCHAR? или несколько разных полей разных типов а при попытки записи\чтения – триггером писать\читать из нужного? Дело в том что значения у каждой из характеристик могут быть разных типов, например Фамилия, Дата рождения, пол
Универсально задаваемые поля
Модератор: kdv
Прочитал статью, хорошая - просто супер рефакторинг - но там тот же велосипед только тремя способами, один - как у меня в вопросе (в статье доп. таблица с названием ATTRIBUTES), второй как у меня сейчас (доп таблица один ко многим), третья через блоб поля
К сож. про то как хранить значения в статье не сказано, только о том что можно хранить их тип и т.п.
А в целом интересен вопрос к умудренным опытом разработчикам
1) используете ли вы единый OID для всей БД а не по отдельным таблицам
2) используете ли единую таблицу OBJECTS и CLASSES как в статье,
--> сам я прочитал статью и заинтересовался но прикинув на бумаге понял что это не идеальное решение т.к. вторичные ключи вообще не получится реализовать (автор говорит фиг с ними - это всего лишь CONSTRAIN) но у меня на них часто ON_DELETE прицеплен для автоматического удаления связанного с удаляемым объектом мусора или что-б не удалил что-то по чему есть движения)
К сож. про то как хранить значения в статье не сказано, только о том что можно хранить их тип и т.п.
А в целом интересен вопрос к умудренным опытом разработчикам
1) используете ли вы единый OID для всей БД а не по отдельным таблицам
2) используете ли единую таблицу OBJECTS и CLASSES как в статье,
--> сам я прочитал статью и заинтересовался но прикинув на бумаге понял что это не идеальное решение т.к. вторичные ключи вообще не получится реализовать (автор говорит фиг с ними - это всего лишь CONSTRAIN) но у меня на них часто ON_DELETE прицеплен для автоматического удаления связанного с удаляемым объектом мусора или что-б не удалил что-то по чему есть движения)