Добрый день.

Проектирую БД. Вот, если коротко, небольшая часть:

Таблица: ТИП ТЕХНИКИ
-ID;
-Название;

Таблица: ПРОИЗВОДИТЕЛЬ ТЕХНИКИ
-ID
-Название;
-Договор;
-Дата заключения;

Таблица: ТЕХНИКА
-ID
-ID тип техники;
-ID производитель техники;
-Название;
-Дополнительное название;
-начальные буквы серии зав.номера;

Таблица: АТРИБУТЫ ТЕХНИКИ
-ID
-ID техника;
-Зав.номер;
-Версия;
-Дата изготовления;

Так вот, есть очень большая вероятность, что через какое-то время потребуется расширить кол-во полей для таблицы АТРИБУТЫ ТЕХНИКИ. Например: адрес установки, дата ввода в эксплуатацию и т.д. На этапе проектирования я не могу знать все эти нюансы. Более того, нет желания возвращаться к этому проекту спустя год и более.

Подскажите, как же правильно спроектировать, чтобы пользователь мог сам через какое-то время добавлять нужные ему поля. Может есть литература, статья или пример. Мне бы увидеть саму концепцию. Дальше сам разберусь.

Спасибо.

Таблица типов атрибутов, таблица атрибутов.

> чтобы пользователь мог сам через какое-то время добавлять нужные ему поля.
> Мне бы увидеть саму концепцию.
ставишь ему mssql + delphi ... готово.

Таблицы с неизвестным количеством полей

Заранее неизвестное количество атрибутов хранимой сущности вовсе не означает заранее неизвестное количество полей физической таблицы.
В первом посте тоже вариант не торт.
Это наверняка если не прямая дорога, то извилистая тропочка в ад.

Медвежонок Пятачок ©   (11.02.13 21:40) [3]

Что тогда торт? Есть примеры, литература?

> sniknik ©   (11.02.13 19:38) [2]
>
> > чтобы пользователь мог сам через какое-то время добавлять
> нужные ему поля.
> > Мне бы увидеть саму концепцию.
> ставишь ему mssql + delphi ... готово.
>

Или платная техподдержка. Имхо, самое лучшее решение.

>Цукор5   (12.02.13 00:35) [4]
>Что тогда торт? Есть примеры, литература?
по EAV есть на удивление неплохая статья на wiki.

>Кщд   (12.02.13 07:47) [6]
это к тому, почему EAV - не торт и тропинка в ад, в чём полностью солидарен с Медвежонок Пятачок ©

А давайте на примере [0]


> Таблица: АТРИБУТЫ ТЕХНИКИ
> -ID
> -ID техника;
> -Зав.номер;
> -Версия;
> -Дата изготовления;

> Так вот, есть очень большая вероятность, что через какое-
> то время потребуется расширить кол-во полей для таблицы
> АТРИБУТЫ ТЕХНИКИ. Например: адрес установки, дата ввода
> в эксплуатацию и т.д.

ну, сколько он там добавит?
ну, пусть, 20.

Почему бы не сделать ALTER TABLE? Да, тупо в плоскость.
+ Словарь таблиц.

При запуске считать словарь, понять сколько полей и где, модифицировать соотв. SQL.

С одним производителем может быть только один договор?

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

Ну, также
Поиски/сортировки/группировки по добавленному
Только изначально надо писать запросы динамические
тестировать на том, что есть на сейчас

> модифицировать соотв. SQL.
не знаю как у вас, а у меня запросы соответствуют логике программы, объединения разные, группировки, и т.д. т.е. чтобы модифицировать, добавить обработку хотя бы одного поля, нужно думать... если же думать не нужно (бывает и так), значит ситуация формализуется, имеет что-то стандартное, что можно запрограммировать и не менять... парадокс однако.
ну вот к примеру этот справочник атрибутов. если он не четкий (количество плавающее) то почему он в плоской таблице? почему не сделать таблицу "заголовок" с не меняющимися параметрами (артикул - наименование - ...) и добавить к ней таблицу атрибутов "в высоту", с такой же жeсткой структурой - id - артикул (для связки) - наименование - значение... - количество атрибутов = сколько записей с требуемым артикулам. все. добавление атрибутов, любого количества, идет в рамках логики готовой программы... ничего добавлять/менять структуру не надо.  

> Только изначально надо писать запросы динамические
а чего мелочится то? динамические запросы... сразу динамическое программирование... т.е. ставишь дельфи... а, ну да, уже предлагал.

посмотрите на 1С, идея была та же, но ничего хорошего (в контексте темы, а не заработка на постоянной поддержке) не вышло. армия "не программистов" ходит по клиентам и меняет "спроектированное" в основных модулях.
думаете "на коленке" изобретете что то лучшее?

> думаете "на коленке" изобретете что то лучшее?

нет


> посмотрите на 1С, идея была та же, но ничего хорошего

именно, глядя на нее и думал.
Сам никогда еще так не делал. Но подозреваю, что трудностей до черта.

Ашот ака Kaif, писал что что-то такое у него юзается.
Вот мне с тез пор и интересно, как сделал.
Он же утверждал, что все работает быстро.

> Ашот ака Kaif, писал что что-то такое у него юзается.
у него gaap (небо и земля с нашей "упрощенкой") + паскаль скрип для "простого" изменения. т.е. то же самое программирование только непосредственно у клиента (тут аналогично 1С-у)

> Он же утверждал, что все работает быстро.
одно другому не мешает. тут "быстро" вообще не по теме (не критерий в топике с лирическим переводом - "сделать так, чтобы настраивалось то, что обычно программируется").

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


А можно подробнее. Ничего толком не понял.

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

> Ничего толком не понял.
придет со временем... или не придет.

А зачем они, эти дополнительные атрибуты, нужны будут в дальнейшем ?

2 Игорь Шевченко ©   (12.02.13 14:14) [16]
Да, нужны. Вам пример из жизни?

Пока пришел к следующему. Делаю обычную реляционную базу исходя из текущей ситуации и прикручиваю EAV для новых атрибутов.

> [17] Цукор5   (12.02.13 14:19)
> Вам пример из жизни?

Хотелось бы.

> Да, нужны


С какой целью ?