Страница 1 из 1

Универсально задаваемые поля

Добавлено: 07 июл 2007, 14:09
break
Есть таблица 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? или несколько разных полей разных типов а при попытки записи\чтения – триггером писать\читать из нужного? Дело в том что значения у каждой из характеристик могут быть разных типов, например Фамилия, Дата рождения, пол

Добавлено: 07 июл 2007, 14:42
Attid
а поиск и сортировку ты потом на клиенте будешь делать перебирая все записи в ручную ?
varchar будет тут единственым решением, но может лучше насоздовать кучу всевозможных полей, а в настройках програмы будешь выбирать какие из них показывать какие нет ?

Добавлено: 07 июл 2007, 19:16
kdv
велосипед. описаний такой модели в инете полно. даже на сайте есть статья Котляревского про ооп в субд.

Добавлено: 11 июл 2007, 18:19
break
Прочитал статью, хорошая - просто супер рефакторинг - но там тот же велосипед только тремя способами, один - как у меня в вопросе (в статье доп. таблица с названием ATTRIBUTES), второй как у меня сейчас (доп таблица один ко многим), третья через блоб поля

К сож. про то как хранить значения в статье не сказано, только о том что можно хранить их тип и т.п.

А в целом интересен вопрос к умудренным опытом разработчикам
1) используете ли вы единый OID для всей БД а не по отдельным таблицам
2) используете ли единую таблицу OBJECTS и CLASSES как в статье,

--> сам я прочитал статью и заинтересовался но прикинув на бумаге понял что это не идеальное решение т.к. вторичные ключи вообще не получится реализовать (автор говорит фиг с ними - это всего лишь CONSTRAIN) но у меня на них часто ON_DELETE прицеплен для автоматического удаления связанного с удаляемым объектом мусора или что-б не удалил что-то по чему есть движения)