Здравствуйте, господа!

Разрабатываем некоторую ИС, которая конечно-же включает работу с документами.

D7+MSSQL

Интересует мнение о модели.
1. Документы хранятся в таблице Doc. Т.е. вернее здесь хранится шапка документа.
2. Детальные данные размазаны по таблицам к примеру DocOrder, DocOrderDetail. Первая - некоторая детальная информация документа, вторая пункты списка на которые распространяется приказ, например список людей.
3. Сохранение документа идет через обычный датасет и обычные гриды
4. Введен термин "проводка", т.е. например при проводке приказа сформируется строка в таблицу EmpMove и там будет указана ссылка на приказ. Отмена проводки понятно что делает. Проводка/отмена вызывается с помощью стандартной ХП, например DocActivate, в параметрах которой указан ID приказа. Для каждого типа документа указаны свои ХП проводки/отмены(они тоже имеют всего один параметр - ID) в таблице DocTypes. DocActivate вызывает процедуру проводки в транзакции и возвращает результат клиенту, также делая запись в историю проводок. Проводки, понятно дело разные, т.е. приказы - проводки по персоналу, а платежка - движение денег на счетах.

Как оцениваете модель в разрезе "не единого" типа доступа к документу(ну что при сохранении не используется ХП)? Спрашиваю потому, что многие разработчики используют ХП для всех операций select\update\delete а мне кажется, что использовать их везде не очень удобно.

Нужно ли реализовывать иереархическую модель проводки документа, т.е. определить классы Документ->Приказ->Приказ на увольнение? насколько реально это нужно? у кого реальный опыт?

LSVНет единственно правильного пути "ХП или update". У каждого свои недостатки.
Иерархия документов очень условное понятие. Если сможете - сделайте. Главное понимать "зачем?" и не усложнить до безобразия.
Нет четкой грани между справочниками, документами и пр. Попытка сделать универсальную иерархию может привести к существенному усложнению.Гм, ладно давайте еще немножко "обсосем" тему ХП, все-таки есть некоторые сомнения и мое недопонимание.

+ ХП удобно отделяет последовательность операций над данными и проводится независимо от клиентского приложения
+ ХП легко модифицировать в отличии от клиента
+ в ХП легко настраивать и проверять безопасность
+ с помощью ХП можно организовать пресловутый 2-ой слой, т.е. слой бизнес-логики, для доступа любых клиентов
- Изменение кол-ва параметров ХП приводит к неработоспособности всех клиентов
- апдейт с помощью ХП добавляет работы при кодировании в отличии от прямого доступа к таблице/представлению
- При выборке с помощью ХП трудно организовать фильтры-построители запросов, т.к. запросы могут быть с ого-го сколькими джоинами и условиями.

это не затрагивая межСУБДшных программ, насколько я знаю, разработчики крупных ERP не любят использовать ХП. Тогда рассмотрим обратную ситуацию. Допустим запросы, выражения SQL выполнены не в виде ХП, тогда их нужно где-то хранить. Собственно варианта два: 1) хранить в неком именованном хранилище(можно и в БД, и в файлах) 2) в самих датасетах. Первый вариант вроде неплох, но опять же обладает недостатками ХП. 2-ой вариант менее удобен, так как вся логика работы с данными будет размазана по приложению, что не есть гуд, да и перекомпиляция светит ярко. Из литературы известно, что работу с данными надо распределять на слои. В случае все на ХП - это соблюдается, а как построить приложение, чтобы выделить этот слой? Мне известен вариант - сделать все на ООП через классы, но тогда прийдется отказатся от визуальных ДБ-компонентов.

Еще вопрос в том как организуется безопасность данных, в том числе и row-level. Думаю что оптимальный вариант - совместить с службой безопасности СУБД. Может быть есть какие-нибудь примеры организации защиты? копание в поисковиках пока удручает, либо не так ищу.

По второму вопросу - вот я и хочу узнать, как определить полезность иерархии, или это определяется целиком оценкой аналитика и архитектора?

AlexTheRavenДля пользователя в GUI такую иерархию построить можно, а вот с точки зрения архитектуры её необходимость сомнительна. Наследование одного документа от других, агрегация, переопределение свойств... Для программистов, возможно, всё легко и понятно, но люди, которые настраивают систему при внедрении - далеко не всегда программисты.Соглашусь, да наверное действительно не нужно без особой надобности мастерить документное наследование. Кстати если ли у кого-нибудь примеры такой потребности?

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

Petro123Аффтар! Вы так и непривели альтернативу ХП. Т.е. ГДЕ будет код проводок и сами транзакции?
Есть 2 варианта:
Бизнес-логика на сервере и на клиенте.Не успел :). Уже привел - некое хранилище SQL-запросов, с которым внутренние объекты программы могут взаимодействовать более тесно чем с ХП. Т.е. например используя макросы(блоки подставляемых SQL-параметров) более легко организовать фильтр для выборки по журналу например.

Petro123всё что ты привёл очень далеко от реальности.
Куда ты денешь ХП - "Провести документ(код)" из 150 строк кода (там не один SQL текст) и 40 вложенных ПОДПРОЦУР и ТРИГГЕРОВ?Почему же далеко? Хранилище у нас есть, датасеты под него заточенные тоже. Все успешно работает. Другой пример все в датасетах подходит в моем понимании в самых простых случаях.

Провести документ - только SQL, который делает проводки. Триггеры вообще не используем. Нотификацией клиента занимается ХП проводки.

Petro1231С попробовало. СУБД только импотентная БД, весь код на клиенте.
Недостатки данного подхода всем известны.Насчет 1С - неудобная штука в плане управляемости(нет доступа к физ.данным), также она не использует преимущества СУБД. Одно интересно - у них четко выделенный слой бизнес-логики - т.е. документы, справочники, журналы и т.д. я считаю что это неплохо.

Petro123Если про слои, то оптимально IMHO 2-х звенка

Клиенты (на любом ЯП - слой представления и событий пользователя)
|
УмнаяСУБД (слой непротиворечивых данных с бизнес-лгикой)
ЗЫ. На уровне программистов свои слои есть.Т.е. нет выделения слоя данных, отдельно бизнес-логики и слоя представления. Тоже вариант.

А слои на уровне программистов - это как?
______________________________________________

==== ну, дык приведи пример процедуры выше без ХП
Ну к примеру так:
т.е. ничего нового вы не увидите ))

Другой пример все в датасетах подходит в моем понимании в самых простых случаях.

============ т.е. если нужно поправить проводку, то заказчик меняет 100 клиентов у одной БД?
Смысл ваших вопросов довольно туманен, либо вы не читали посты. Конкретно проводку? ХП Проводки получает ОДИН параметр - ID документа. Так что здесь унифицирован подход, клиентов менять не надо. Тоже самое легко реализуется из хранилища выражений.

Petro123Если про слои, то оптимально IMHO 2-х звенка
Иногда оптимальнее трехвенка.

== просто данные (как было в *.DBF никому ненужны). И выделять их смысла нет.
Тут я с вами не соглашусь, данные важны для организации взаимодействия систем, притом чем больше способов интеграции, тем лучше. Доступ к БД - самый низкоуровневый вариант и довольно часто бывает восстребован.

Александр Федоренкомного способов обойти этот минус:
1. пишешь процедуру с тем же именем и увеличенным количеством параметров. Работают и старые клиенты и новые.Да это работает.. пока параметров <30, дальше уже по-моему маразм. Александр Федоренко2. На клиенте написан вызов процедуры исходя из ее зарегистрированного описания - поменял процедуру, поменял ее описание - старый клиент работает по-новому, ну почти :)Интересный механизм. А как он будет сопостовлять параметры?
Александр Федоренко softale- апдейт с помощью ХП добавляет работы при кодировании в отличии от прямого доступа к таблице/представлению
Ну опять же, смотря как системная часть клиента организована. Может даже наоборот - уменьшает.Можете привести пример?
В моем понимании так: делается запрос, результат в DataSet. Все. Остальным занимается он. Каким образом можжет быть проще?
Александр Федоренко softale- При выборке с помощью ХП трудно организовать фильтры-построители запросов, т.к. запросы могут быть с ого-го сколькими джоинами и условиями.
Это тоже нетрудно решается: запрос в хранимке использует таблицы фильтров, причем стандартно. Тоже интересно. А как идет сборка условий запроса и последующее его выполнение в ХП?

Александр ФедоренкоУ нас подсистема доступа была реализована в ХП и встроена во все ХП. Все проверяется и разрешается на сервере. Субьекты: пользователь, подразделение и роль. Объекты: логические объекты, в рамках которых реализована вся информация, хранящаяся в СУБД и, соответсвенно свойства и методы этих объектов. Правила доступа можно накручивать по ходу разработки и правится одна ХП. Клиенты имеют право только на ХП и еще временные таблицы.Да на ХП это можно сделать... В ХП удобно делать Row-Level security, но у меня есть опыт создания view с аналогичными функциями. Т.е. представлние показывает только то, что доступно пользователю. Функции работы с объектами, ролями, пользователями у нас тоже в ХП. Но неужели не разумней выдать прямые права на доступ к таблице, скажем простому справочнику(в соответствии с правами), а не городить к нему обработку в в виде ХП?

softwarerДовольно малоосмысленное утверждение. Представьте себя на месте программиста клиента, вызывающего клиентскую процедуру Xyz. Какая ему разница, что именно делается внутри этой процедуры:

1. DataModule.StoredProcXYZ.Execute?
2. DataModule.QueryWithXYZScript.Execute?
Представляю четко. В случае системы которая стоит у заказчика, гораздо легче будет обновить ХП\SQL-выражение в хранилище, чем клиента.

softwarer softaleи проводится независимо от клиентского приложения
Это самоцель?Я думаю, что теоретиков здесь трется немного, поэто целью любых телодвижений является упрощение разработки\сопровождение. Выводы сделайте сами.[/quot]
softwarer softale+ ХП легко модифицировать в отличии от клиента
И легко потерять синхронность версий ХП и клиента.С кривыми руками можно вообще много чего наделать. Так может вообще ничего не писать? Каждую конкретную ситуацию надо смотреть отдельно - неужели вы утверждаете, что менять клиента ВСЕГДА проще чем менять ХП?

softwarerНу-ну. Может конечно и существуют инструменты, умеющие взять "слой из ХП" и сделать с ним что-то разумное, но на практике как только ставится задача "любых клиентов" (а практически - неизвестной заранее отчетной системы), так сразу оказывается, что единственно приемлимый второй слой - таблицы и вьюхи.Согласен.

softale- Изменение кол-ва параметров ХП приводит к неработоспособности всех клиентов
Странный минус. Необратимая перестройка интерфейса - например, добавление not null поля в таблицу - приводит к неработоспособности клиентов вне зависимости от того, используют они ХП или нет.[/quot]Ну тут тема про варианты обновления... фиг с ним не будем рассусоливать.
softwarer softale- апдейт с помощью ХП добавляет работы при кодировании в отличии от прямого доступа к таблице/представлению
Если Вы имеете в виду ADO-шную привычку автогенерить код обновления, то это весьма сомнительное преимущество. Из серии тех, что красиво выглядят в демонстрационных примерах уровня "записная книжка".Хм. чем он вам так не угодил? Что в нем плохо? Я имею ввиду что механизм обновления по дефолту основан на проверке того, изменял ли кто нибудь ту запись, которую корректировал клиент. В случае не использования этого механизма - это приходится делать вручную. И зачем мне это сщастье, если оно мне не надо?

softwarer softale- При выборке с помощью ХП трудно организовать фильтры-построители запросов, т.к. запросы могут быть с ого-го сколькими джоинами и условиями.
Факт. Выборка с помощью ХП в большинстве случаев - глупость. Хотя табличные функции MSSQL здесь могут оказаться весьма уместными.Скажу что такое решение все равно проиграет по удобству. Да и реализацию затрудняет, увеличивая время разработки.

softwarer softaleСобственно варианта два: 1) хранить в неком именованном хранилище(можно и в БД, и в файлах) 2) в самих датасетах. Первый вариант вроде неплох,
Первый вариант очень плох. Он сочетает минусы всех вариантов, и осмысленен только если над ним нагроможден офигенных размеров собственный фреймворк.Ну так поясните почему. Я лично никаких проблем от его использования не усматриваю.
softwarer softale2-ой вариант менее удобен, так как вся логика работы с данными будет размазана по приложению,
Cкажите тому, кто размазывает, что он ламер - в следующий раз не будет размазывать. Очень умно. Ладно, это все-таки холиварный вопрос, не буду развивать.

softwarerСлой - это то, что Вы считаете таковым. Если программист пишет что-нибудь типа


ХП ему не помогут, дешевле пристрелить, чтобы не мучился.В большинстве случаев согласен. Исключением для меня является возможность ADO генерить рекордсеты по прямому запросу от соединения. К примеру для получения текущео времени:
Повторяю - только в самых простых случаях, дабы не плодить датасеты.

softaleЗапомните как факт: все, что можно сделать на ООП, можно сделать без ООП. И если в первом случае будут "слои" - куда они денутся в абсолютно аналогичном коде без ООП?)))) про ООП это вы даете. Это само собой разумеется - не встречал программистов, которые после толики убеждения не соглашались с ним. Другое дело удобно ли?
Что в вашем понимании есть слой - физически и логически?

SergGol
Был опыт.
1. В одной из КИС все документы делаются в некотором построителе документов. На документ вешаются некоторые стандартные (или не стандартные, если нужно) операции, которые отражают содержимое в учетных регистрах (БУ, складские партии и пр.). Порядок проведения операций тоже настраивается некоторыми параметрами. В процессе внедрения для товарных документов (приход, расход, перемещение, списание, оприходование и пр...) были созданы отдельные типы документов (что естественно). Причем на каждый из типов по нескольку разновидностей, в зависимости от потребностей. Причем порядок отражения ТМЦ в регистрах складских партий в кажом типе настраивается отдельно, почти одинаково, но отдельно. Это было достаточно неудобно для сопровождения.А как у вас был определен набор операций? Т.е. возможно ли задать нестандартные документы, со своим интерфейсом и нестандартными операциями?

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

skipped

softwarerСкажем, отсутствие внятной проверки ошибок. Отсутствие внятного редактирования данных из нескольких таблиц. Да собственно отсутствие всего, что выходит за минимум уровня "раз-два, левой".Что такое "внятная проверка ошибок"? Все необходимые данные в обработке исключений присутствуют. Что выходит за уровень "раз-два"? Вы полагаете что в АДО невозможно организовать нормальной работы?

Далее порезал, потому что видно, что у Вас претензии к АДО.

softwarerВ-нулевых, когда под боком БД, придумывать еще какое-то отдельное файловое хранилище малосерьезно, не тот повод, все те же минусы плюс дополнительный геморрой. Поэтому давайте смотреть только что касается БД.А как же запросы на клиенте? Собственно какая разница где хранится запрос?

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

softwarerВо-вторых, для такого хранилища максимальна вероятность разъезжания версий как между "запросами и сервером", так и между "запросами и клиентом". Организован теоретический максимум мест, в которых можно огрести проблему.Вероятность расползания версий точно такая же, как в случае ХП. Убедите меня в обратном.

softwarerВ-третьих, при этом конструкция лишена и главного плюса клиентских запросов - удобной отладки. Придется либо громоздить довольно много своего кода, либо запускать приложение каждый раз, когда захочется увидеть, как данные легли в интерфейс, удачно ли выбраны дефолтовые размеры колонок в гриде, да в конце концов нет ли в запросе синтаксической ошибки.Ну тут подпункты. Скажем отладка в MS SQL меня все-таки никогда не возбуждала. Запускать приложение надо всего один раз, далее идет работа с редактором выражений, где его можно запустить и проверить. Притом при использовании выражений удобно использовать подстановку значений параметров(сразу заполнять имя пользователя, период и т.д. без лишних движений) и макросы фильтров, чего никак не скажешь о ХП.

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

softwarerВсе это - при отсутствии плюсов, точнее, при единственном мифическом "трудно обновлять клиента".Вообщем я изложил по-пунктам, а Вы все-таки абсолютизируете.

softwarer softaleИсключением для меня является возможность ADO генерить рекордсеты по прямому запросу от соединения. К примеру для получения текущео времени:....
Это не следует рассматривать как исключение. Никто не мешает Вам объявить функцию GetDate с указанным Вами содержимым в том, что Вы сочтете "слоем доступа к БД", все будет строго концептуально послойно. На самом деле так и реализовано. )))
softwarerХотите менее строго - да опять же, Ваш вопрос, не возражаю: я подчеркиваю, что "перенос всего на ХП" не дает Вам чего-то нового, чего Вы не имели бы в случае запросов на клиенте. Конечный смысл моего аргумента - то, что Вы считаете фактором разницы между подходами, на самом деле никакой разницы не описывает, одно и то же можно без проблем сделать в обоих подходах.Дает прозрачность SQL-запросов независимо от клиента. Конечно надо пользоваться такими штуками с умом и не пихать где ни попадя.
softwarerЧто касается подхода "не плодить лишних датасетов", я одобряю его до тех пор, пока он не доходит до экстремизма вида "использовать один датасет вообще для всего".Такого не встречал.

softwarerВполне удачное определение имхо дано в Wiki - я бы только отметил, что не обязательно увязывать понятие именно с классами, "модуль" здесь выглядит ничуть не хуже.Поделитесь тогда мыслью как разработать "слоенный" фреймворк и стоит ли вообще это делать? Я пришел к тому что оптимальной является структура вида

БД
|
Модуль соединений(менеджер соединений, классы датасетов)
|
Модуль базовых форм и компонентов, движок управления приложением
|
Функциональные модули

в эту схему надо вписать еще и приложение и ядро, которое управляет всем этим, конкретного места в лоях они не имеют, поэтому стоит поставить в сторонке.