С целью ведения учета в связи с новыми обстоятельствами (я про новые атрибуты). Вторая задача: не переделывать структуру БД , т.к. нет желания возращаться к этому проекту спустя какое-то время.

Пример из жизни.
Есть некая техника (предположим, кассовый аппарат) со следующими атрибутами (зав.номер, версия, дата изготовления, дата ввода в эксплуатацию).

Прошел год. Государство решило ввести новую норму закона и каждому аппарату присвоили фискальный номер. Более того, заказчик теперь обязан во всех документах указывать этот фискальный номер.

Прошел еще год. Государство опять изменило норму закона и теперь к каждому аппарату "цепляют" модем. Добавляем: тип модема, зав.номер модема, ID_DEV модема. И опять во всех справках и отчетах эти новые атрибуты.

И так примерно каждый год. Что-то отменяется, что-то добавляется.

> > Он же утверждал, что все работает быстро.
> одно другому не мешает. тут "быстро" вообще не по теме

по теме

Идет запрос на определение, разбор что там есть, генерация нового SQL на основании "метаданных"
Это долго.
Например, как в 1с, вводим новую таблицу, специально под конкретную группу товаров, со своими хар-ками
user все задает и мы делаем Create table

Потом, запросами к метаданным, получаем эту таблицу, имеем  поля, их типы, ссылки FK|PK таблицы
(ну, что бы в гриде можно по клику на поле еще грид показать, с соотв. таблицей, на которую ссылается, и т.п.)

Например, на опредление структуры одной таблицы (Oracle)



работает примерно 8-10 секунд
получим
EQUIPMENT EQUIPMENT_TYPE_ID NUMBER(22)NOTNULL "Тип оборудования."
EQUIPMENT EQUIPMENT_TYPE_ID EQUIPMENT_TYPE ID
теперь можно в гриде по клику на поле, еще грид показать, с соотв. таблицей, на которую ссылается, откуда можно выбрать значение или вставить новое, при этом  можно по клику на поле, еще грид показать, с соотв. таблицей, на которую ссылается
ну и  так далее.

т.е. заранее иерархия справочников не известна. И юзер теоретически ее может сам посторить.
И ее надо вычислять по мере продвижения

ps
еще раз - сам не пробовал. Просто думаю.

Что мешает все эти нововведения хранить в одном месте, не по-атрибутно ?
Я спросил, какая цель именно в необходимости добавления отдельных атрибутов, полей, таблиц и т.п.

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

Если хочется сделать одно приложение для всех грядущих отчетов на все возможные случаи жизни, это, по-моему, утопия. Если хочется добавить возможность пользователю самостоятельно конструировать новые формы отчетов по мере изменения внешних обстоятельств, то зачем ему вообще какое-то приложение ? excel и access вполне достаточно

> Что мешает все эти нововведения хранить в одном месте, не по-атрибутно ?
+
судя по описанному [20] никаких обработок, поисков, фильтраций т.е. работы с данными не предполагается, т.е. мемо поля хватит на все. т.е. без смены структуры. в отчетах мемо поле легко отображается.
условия соблюдены.

> генерация нового SQL на основании "метаданных"
> Это долго.
у Ашота этого нет, ... ну, не нужно по крайней мере. в скрипте структура также известна и также не требует "на основании" как при обычном программировании.

p.s. чето через чур "8-10 секунд"? mssql + схемы ado структуру мгновенно определяют. может с миллисекундами спутал?

> [20] Цукор5   (12.02.13 15:06)
> во всех документах указывать этот фискальный номер

> [20] Цукор5   (12.02.13 15:06)
> И опять во всех справках и отчетах эти новые атрибуты.

> [20] Цукор5   (12.02.13 15:06)
> И так примерно каждый год. Что-то отменяется, что-то добавляется.

Кто всё это будет переделывать?

> никаких обработок, поисков, фильтраций т.е. работы с данными
> не предполагается


Еще как предполагается.


> Кто всё это будет переделывать?


Я, например.

Вероятно, я плохо объяснил. Пардон. Идея в том, чтобы каждый раз при появлении новых атрибутов не править базу(добавлять/изменять/удалять таблицы или некоторые поля таблиц). Естественно, при появлении новых атрибутов возникнет необходимость делать формы, запросы, отчеты и т.д. Это я понимаю и готов к этому. Повторюсь, хочу лишь определиться со структурой базы, чтобы можно было не заглядывать туда лет 10.

Извините, если плохо объяснил.

> у Ашота этого нет

да?!
Блин, тогда как же он спроектировал так ловко..
зы. Скачать что ли уже, посмотреть  :)


> p.s. чето через чур "8-10 секунд"?

да, именно секунд.
А и говорят, что MSSQL лучше мета поддерживает.

Возможно, не оптимально написал и можно как-то иначе.
Возможно, >> говорят, что MSSQL лучше мета поддерживает
именно такие же

Просто мне пока для анализа хватает.
ps
Хочу написать свой построитель схем БД :)
Как в MSSQL.
Сколько искал - не то все. Тоад не нравится(нравится, но он "рисует не правильно:)" ), PLSQL - тоже.

Хочу написать простую для юзания программку, аля запустил, имя схемы вбил, пошел курить. Пришел - все построено (и отображается как в MSSQL !)

> [26] Цукор5   (12.02.13 17:04)
> Я, например.

Тогда сабж блажь.

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

> а кто-то наоборот все на sql процедурах пытается, типа,
> "шоб после программу не пере-компилировать на каждый чих". и тоже блажь.
А что тут-то не так? :)

2 Inovet ©   (12.02.13 17:13) [28]

Что тогда не блажь? Как бы Вы сделали?

> [31] Цукор5   (12.02.13 18:03)
> Как бы Вы сделали?

Изменял структуру базы и приложение в соответсвии с новыми требованиями. Для перевода базы на новую версию достаточно выполнить SQL скрипт, например.

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

> sniknik ©   (12.02.13 19:57) [33]
у нас и переделка отчета не ведет к перекомпилированию. ;)
вернее так: если это не касается интерфейса диалога с пользователем (или чегото подобного) то перекомпилировать не надо, иначе никуда не деться.
Ну так это и есть - "по любому чиху".
А вот когда приходится перекомпилировать без особой на то необходимости, а просто потому что все в ехе, вот тут действительно "руки страдают"... :)

> проверь на предмет копий процедур
при разработке копий всегда хватает. периодически чистим...
иногда меняются условии так, что просто делаем рядом новую, а там "поглядим".

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

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

> без особой на то необходимости
я про то и говорил, она есть ВСЕГДА. т.к. причина всегда клиент (не, я конечно слышал, что где то там, есть что то, что не всегда... воспринимается как миф, без подтверждений в жизни). вот ты тут тоже сказки рассказывать пытаешься.

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

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

Элементарно. Посмотри, как этот вопрос решен, например, в DocsVision

А как смотреть? Продукт не бесплатный:
http://www.docsvision.com.ua/costs/

Выдержка с другого форума:"Ничего плохого в EAV нет. Если под текущий размер базы выделены достаточные аппаратные ресурсы и в базе в нормальном виде расставлены индексы, то самым тормозным местом будет явно не база. Так что «советчиков» которые без конкретных аргументов так говорят можно сразу спокойно слать лесом.".
Полностью согласен с этой точкой зрения.
Никто структуру/запрос EAV не приводит для примера, а на самом деле там все просто. Если надо набросать примерную схему - нет проблем.
Интерфейсная часть решается через древовидный список, как здесь уже писалось. Есть заковыка с типами атрибутов, но это тоже достаточно просто решается (есть, по крайней мере 3 способа).
А каждый раз таблицы менять - это крайне неудобно и требует лишних усилий.
Вот JOIN'ы в часто выполняемых запросах - это зло.

> [38] IronFox ©   (19.02.13 10:15)

Да ради бога, усложняй себе жизнь, кто же против.