Еще один подход. Программный комплекс БАС

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

Например, в таблице операций есть поля "цена, количество, сумма", которые были созданы при настройке операции "Счет-фактура". Пользователь создает новую операцию "Накладная на отпуск", параметры которой хранятся в той же таблице. Пока он добавляет поля "Количество, цена, сумма" - ничего с базой данных не происходит. Но когда он решил добавить поле "Текущий остаток на складе", система уведомляет его о необходимости изменения структуры, которая выполняется нажатием кнопки, расположенной на той же панели настройки. Все изменения структуры проходят автоматически, "за кадром".

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

PS Имхо. Вообще, пользователям это не надо. Это очень удобно программистам при внедрении и сопровождении системы. .

pnv82-=Под лежачего программера пиво не течёт=-
With best regards, Nikolay Ponomarenko Но иногда из под него вытекает... Парадокс!!!

pnv82[quot PVP]Не, это как раз и есть третий подход - прямые ddl операции в БД :)
Т.е. судя по всему, больших проблем такой подход при эксплуатации не вызывает?Вообще ни каких проблем. Работает с 2002 г на многих предприятиях. Одно удовольствие. Вы просто работаете с операциями, справочниками, отчетами, не заботясь об изменениях в базе данных.

проца ввести новый справочник, документ ?Без проблем. В справочник справочников добавляете новую запись, называете его, набираете состав параметров, определяете к нему доступ и можете использовать.

проца если новый атрибут не скаляр а таблица ?
а если атрибут был скаляр а надо изменить на таблицу или наоборот?А если изменилась операционная система, а если поменялась СУБД, ... Не надо расчитывать на абсолютно все случаи жизни. Достаточно только для той области, для которой предназначена система.

процэто самое сложное. никогда не знаешь как расширится область, поэтому и надо закладывать max возможного Бесспорно. Только с одной маленькой поправочкой "в пределах возможного". Имеется в виду время и деньги.
проц(а приведенные примеры типичны)Не ради рекламы. Только средствами настройки, не прикасаясь к структуре базы другими инструментами, одна и таже база данных прикладного модуля БАС и один и тот же bas.exe превращаются (с виду) в совершенно разные задачи - бугалтерия, склады, зарплата, работа с населением, CRM-Услуги, платежи населения, производсто и др., Это достаточно широкая область. Одолеть бы хотя бы ее.

Visitorглавное чтобы живые деньги и вовремя...А если на разработку потрачены деньги свои? Старался со всех сил, платил другим программистам несколько лет, а когда сделал то что хотел, оно уже морально устарело и никому не нужно. У меня так было с версией DOS. Или еще лучьше, деньги кончились и в долг уже не дают еще до того, как разработка закончена.