2 Vadimkp

Нужно спроектировать базу данных, структура которой может меняться.

Я не Гуру, и не хотел бы я этим заниматься в серьез :-) но это вполне возможно.

Например, в 93 г. я на заводе внедрял некую бух_систему. "Турбосальдо". Она была написана на foxbase. Испрользуя по полной программе механизм макро_подстановок foxbase (когда для получения значения переменной - можно динамически задавать ее ИМЯ ) - авторы "Турбосальдо" сотворили чудо.

1. Они один раз написали оболочку.
2. Они завели свои журналы ...Задач, Таблиц, Полей таблиц.
3. Они на АВТОМАТЕ !!! для любого описалово_любая_таблица_бд = автоматически выдавали ИНТЕРФЕЙС для ввода данных.
4. Они на АВТОМАТЕ для любого описалово_любая_таблица_бд = выдвали отчет.

Собственно, оболочка - и была единым инструменом - для системщика и для бухгалтера.

Когда я при внедрении вдруг понимал что мой ID (артикул например) - надо увеличить длину поля - я просто в журнале менял атрибут. и ВСЕ!!!!

Если я при внедрении вдруг понимал - что нужна ИЩО одна поляна....я просто добавлял строку в журнал таблиц. И ВСЕ!!!

А еще я мог у любой поляны изменить ее ТИП ДАННЫХ.!!!!!!!!!!!!!!!!!!!!!!!!!

Если мне нужен был свой алгоритм - я просто писал на foxbase свой *.prg и под своим именем - прописывал его в журнале задач (расчетов). и ВСЕ!!!

Сегодня можно смотреть идею реализованную в КИС "Альфа". Там можно "на лету" создавать любой состав и уровень аналитики ( в части например, товаров).

Другой пример - это идея ....от виндов. Иконки. То бишь - ярлыки. ЛИНКИ.

Данные могут храниться в БД один раз и в одном месте. Но для представления - можно создать любое кол-во Ярыков к ним, с любым кол-вом собственных групировок....(ЯРЛЫК на ЯРЛЫК).

Грубо говоря - можно иметь всего одно "деревяное табло".

Где сущности - это строки. Где Узлы - имеют свои строки + АТРИБУТ. Если интересно - можно продолжить.....

2 Vadimkp
Это все работало быстро!. Ибо на диске всегда лежала коллекция dbf файлов, с которыми (в расчетных програмах) система работала напрямую, минуя какие либо соглашения. Оболочка - она токо "автоматизировала" сам процес разработки/модификации БД.

Про интерфейс. Тут вообще интересно. В цехе 1000 рабочих, зарплату надо "вогнать" быстро, наряды, табели, премии... И их интерфейс - это чудо. Я сам набивал списки - и удивлялся - как как это так, на экране чисто - даже не бланковка - а просто - поля ввода - сверху в них, в две колонки

типа так

Имя поля по русски Поле ввода
-------------------- ------------
Табельный номер......ХХХХХХХХХ
Номер цех................ХХХ
Номер участка..........ХХ
Вид оплаты...............ХХХ
..............

И если полей ввода много - то все в две колонки. (все это для одного рекорда естественно)

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

...что то мне еще захотелось "потрепаться"...

Таким образом - предметом системного программирования является сама Оболочка.

Вот вам готовое решение - три компонента.

1. FormBulder
2. FormRuntime
3. ORACLE.

Если вы это юзаете + ведете свой в БД "тупой" словарь имен рантаймов - то получаете в свою систему ВСТРОЕННЫЙ ГЕНЕРАТОР ЭКАННЫХ ФОРМ. Ибо вашей системе будет все равно что запускать - рантайм или билдер с исходником. (это вообще то и для других справедливо)

(вчера буквально, я по телефону....подвинтил маргинсы у печатной бланковки....юзеры у меня ....по телефону...открыли генератор отчетов и мышой там по кликали...)

Теперь про словарь БД. когда мне надо было довести до ума подстему доступа.... за 2 дня создал ....почти "кэйз"...журнал объектов БД + русские имена + скрипты генерации..чего_то_там.....

Это лобовое решение - когда вы в своей системе реализуете механизм (интерфейс) модификации структуры БД + юзаете (интегрируете) уже готовые билдеры. (типа дать стринг на ALTER TABLE ADD name_field....)

на каждый интервал трафика нужно фиксировать сколько Мб из них бесплатно - получается нужно добавить поле.

Другое решение - вы можете - реализовать механизм типа ПРОВОДОК.
Если в первичный документ юзер вводит (в 1 строку) 100 рублей, то по вашей гибкой настройке, эти 100 рублей могут быть разложены на произвольные "ячейки" путем создания (произвольно) дополнительных строк в ДРУГОЙ таблице.

Так же и аналитикой - каждая строка документа - может быть "привязана" к произвольному кол-ву аналитик - через дополнительное табло.

(В КИС АЛЬФА так и поступили....токо их интерфейс подводит).

Имея соглашения, модель БД в системных журналах, можно абстрагироваться от типов данных....и все "ПРОВОДКИ" хранить типа тупо в CHAR (2000)....
Или - в NUMBER и CHAR

появляться новые услуги, со своими атрибутами (полями).

путь ваши атрибуты - это строки в справочнике. Услуги - это узлы дерева, в узле перечисленны атрибуты. Остается токо решить как хранить валуе. Для всех типов валуе - достаточно всего одной поляны....



так примерно можно здесь рассуждать....


















.