2 Yossarian: \r
Прежде всего : абсолютно непонятно, о чем идет речь. \r
\r
Кажется, что человек сам не понимает, что хочет спросить или не может выразиться грамотно и ясно. Напоминает типичный программисткий вопрос на тему проектирования: "у меня - вот, вот, вот.., а как вот, вот, вот чтобы ВОООООООТ?" :о)\r
\r
2 TimKa: \r
Короче говоря, хотелось бы применить обьектно ориентированный подход на серверной стороне, или хотя бы сымитировать его, чтобы не писать отдельно библиотеку ХП для каждого типа документов. \r
\r
Для этого даже и не надо другого подхода, используйте пакеты ХП, например, такое есть в PD. Сгруппируйте в них объекты (таблицы, виды), относящиеся к какой-либо предметной области , например, "Бухгалтерия", затем туда же всю логику (триггеры, ХП) и уже проще будет вести разработку БД. Для клиента тоже самое: старый способ - группировка артефактов (моделей, диаграмм, классов, компонентов) в пакеты по бизнесоперационному, функциональному или операционно-ролевому признаку:\r
\r
на концептуальном или логическом уровне это соответсвующая иерархия UML-пакетов\r

на уровне реализации это UML-пакеты со стереотипом подсистемы или физические компоненты (типа exe, dll, ocx, tbl)\r
\r
Динамическая генерация получается как-то криво, возврат параметров делать трудно, может быть я вообще на ложном пути и надо быть проще, наплодить для каждого документа своих процедур и успокоиться? \r
\r
Извините, но все это звучит несколько бесмысленно про "Динамическая генерация" и "наплодить для каждого документа своих процедур" потому что неясны причины побудившие вас выбрать тот или иной подход. Вы сначала обрисовали бы какую-нибудь хотя бы одну типичную подзадачу вашей предметной области, к-рая с документами, например, а после какой сервер (данных, приложений) собираетесь использовать и затем конкретные вопросы "а если вот так, то какие плюсы-минусы". Тогда уже и можно говорить о том как лучше делать, а то все мучаются в догадках\r
\r
2 aag: \r
ИМХО, серверная часть в определенном смысле противоположена обьектно-ориентированному подходу. Потому любые попытки создать что-то - как в ОО, обречены на многочисленные компромиссы. \r
\r
А что значит "в определенном смысле противоположена"? Реляционная серверная часть может и противоположна, если там промежуточного слоя нет, к-рый эти "объекты" эмулирует. Однако писать его действительно необходимо в случаях когда количество и тип объектов предметной области может менятся по желанию пользователя как, например, в Хранение произвольного кол-ва параметров\r
\r
Попробуй создать структуру БД без оглядки на ОО, используя нормализацию таблиц. \r
\r
Это же неправильный подход, в смысле не про нормализацию базы, а про создание приложения "от данных" (структурный подход, а не ОО) или проектирование БД отдельно от приложения

2 TimKa: \\r
Я действительно не достаточно точно могу сформулировать, чего хочется, но в самом сжатом виде вопрос, как мне кажется, звучал бы так : "как организовать на серверной стороне инкапсуляцию кода , наследование классов, и прочие приятные вещи, присущие обьектному стилю программирования". \\r
\\r
Я бы не стал изобретать велосипед или сразу бросаться в крайности с MSSQL и TSQL, а принял бы сначала стратегическое решение: какой тип архитектуры мне нужен и какой тир/звено/уровень (tier) или слой (layer) за что будет отвечать. Что-то вроде выбора архитектурного шаблона, исходя из "тяжести" унаследованного вами уровня данных. Действительно я бы тоже не стал переписывать БД, если....\\r
\\r
ее нельзя трогать, т.е в ней критические данные или они должны быть\\r
постоянно доступны (у вас такой случай?)\\r

ее лучше не трогать, т.е ее переделка эквиалентна созданию новой БД что\\r
може затянуться надолго, а результат нужен быстро (у вас именно такой случай)\\r
\\r
При этом пришлось бы оговаривать, что я понимаю, что TSQL, скажем, строго процедурным назвать нельзя, что строгая и гибкая типизация невозможна и так далее и тому подобное. \\r
\\r
Однако странная привычка оговаривать то, что как раз не нужно. Вы думаете это на SQL.RU мало кто об этом знает или в вашу тему набьются ораклоиды и будут вам рассказывать про PL/SQL и объектные типы? Пусть потрудятся впустую как говорит Дед Маздай, но я думаю вы зря беспокоитесь заранее :о)\\r
\\r
Меня интересует, как поступают опытные программеры баз данных, если им приходится содержать кучу похожих, но не совсем равных структур данных с кучей похожих процедур их обработки. \\r
\\r
На основе только этого высказывания опытный программер баз данных скорее всего не поймет, что именно вы имеете в виду 8о\\r
\\r
Теперь конкретный вопрос - что такое PD и где почитать про пакеты? \\r
\\r
PD = Sybase PowerDesigner . Самое лучшее (по сумме характеристик) и удобное CASE- средство разработки БД и ООАП\\r
\\r
В любом ОО языке высокого уровня я бы написал основной класс и плодил бы от него сущности по необходимости. \\r
\\r
Если нужно "плодить" ОО, то возможны 3 варианта:\\r
\\r

использовать ООСУБД типа Intersystems Cache\\\' (сравнения)\\r
- этот вариант мне нравится больше, а учитывая некую перспективность Cache,\\r
ее растущую популярность и совершенствование как СУБД, а также развитость ее средств\\r
разработки для VB и Rational Rose;\\r

использовать сервер приложений (Java или .NET) и РСУБД\\r
- сервер приложений в качестве промежуточного звена для бизнес-логики, к-рое позволит\\r
вам ее легко компонентно обновлять, но проблему с постоянно изменяющейся\\r
моделью данных он сам по себе не решит;\\r

использовать ООСУБД и сервер приложений \\r
- тогда вы вообще сможете использовать и ООБД и богатство возможностей, например,\\r
той же J2EE\\r
\\r
Предметная область простая и в тоже время вечная - учет и организация процессов на торгово-производственном предприятии... \\r
\\r
Учет это понятно, а "организация процессов" какое отношение имеет к работе вашей ИС?\\r
\\r
Взять к примеру передвижение мат ценностей - каждый документ (заказ, резерв, заявка на сборку, заявка на склад, отгрузочные, накладные на перемещение товара итп итд) имеет свою форму и в то же время все имеют обязательные поля, как бы происходит от одного абстрактного класса "документ". Методы работы с ними тоже во многом схожи, за исключением того, в каких дополнительных таблицах какие проводки делать при актуализации документа. \\r
\\r
Да, ОО подход конечно хорошо описывает реальный мир с его наследованием и полиморфизмами, но причем здесь это? [colo=red]Если у вас на предприятии множество документов и тип документов меняется досточно редко , то зачем вам ОО? Такую документную модель с ее бизнес-логикой можно прекрасно реализовать и с помощью реляционного SQL Server. Вы себе проблемы случайно не ищете?\\r
\\r
поэтому и возник вопрос, так как захотелось приблизить существующующую систему к жизни, упростить реконфигурацию итп. Раньше для того чтобы добавить одну операцию (а значит комплект документов) в процесс, приходится перелопачивать кучу кода. \\r
\\r
Звучит странно насчет "перелопачивать кучу кода". Я верю вам конечно, но...откуда куча и как часто эту кучу приходится перелопачивать? Далее: проблема даже интереснее, если у вас организация в к-рой очень часто возникают новые типы документов и еще операции с ними. Хотя это вообще ненормально с самых разных точек даже современных точек зрения. Это вам даже может подтвердить "Yossarian" (я знаю, что он известный знаток самых разных предметных областей). Не расскажите хотя бы кратко почему это происходит? :о)\\r
\\r
Потом я организовал все инкапсуляцию на клиентской стороне, т.е. завел родительский модуль класса (пишу на VB), в нем описал все методы доступа и работы с таблицами, метаднные вынес в отдельную таблицу, а запросы формировал на основе метаданных. Стало лучше - теперь чтобы завести документ, надо просто скопировать заготовку таблиц, добавить нужные поля, и завести на него строку метаданных...... \\r
\\r
Ясно - сплошное эмулирование ОО. Cache вам очень облегчила бы жизнь в этом плане, если у вас действительно такая непоправимая ситуация с документооборотом. Тогда вам осталось бы приделать к ней соответствующий интерфейс на VB, использующий, например, ActiveX-контрол Cache Object Link\\r
\\r
Можно вопрос поставить еще более обще, как писать код для сервера, чтобы базу можно было легко сопровождать, удобно дополнять под текущие нужды и модифицировать без лишних проблем, не перестраивая полностью, но такая поставновка как мне кажется вызовет излишний флейм. \\r
\\r
Более обще не надо! Вообще это (сопровождать, удобно дополнять) с написанием кода наверное никак не связано. Это определяется средствами в том числе CASE, с помощью к-рых БД разрабатывается, например, тот же PowerDesigner позволяет решать такие насущные задачки:\\r
\\r

удобное проектирование (прямое, обратное) модели данных с синхронизацией БД;\\r

удобное редактирование SQL кода, использование шаблонов и т.д;\\r

удобный контроль версий и изменений (групповая разработка)\\r
\\r
Но ваш вопрос, учитывая все вышесказанное имел в виду ведь другое - какова должна быть архитектура/БД системы чтобы базу можно было легко сопровождать, удобно дополнять под текущие нужды и модифицировать без лишних проблем, не перестраивая полностью,..

В Китайской народной республике сдана\\r
в строй новая электростанция мощностью 10 МВт.\\r
10 миллионов китайцев заколебались бегать\\r
в шерстяных трусах вокруг эбонитовой палочки. \\r
/*детский анекдот советских времен*/\\r
\\r
2 TimKa: \\r
Простой вопрос, который, судя по форуму, возникает достаточно часто у людей, "почему я не могу сделать без особых проблем SELECT $z.a,$z.b FROM $z" где $z-переменная. Ведь это никак не противоречит реляционной модели, но как бы помогло сократить и унифицировать код, а, главное, создавать новые сущности со своими свойствами. ))) \\r
\\r
"Yossarian" уже ответил на вопрпос, я только добавлю по поводу реляционной модели (как некой системы объектов, правил и операций для этих объектов ): просто нет никакой такой "непротиворечивости" ей SQL как языка. Вообще SQL может и нужна эта модель, а точнее ее понятия посколько он работает с такими понятиями как таблица, ключ, джойн, например, да и то SQL-99 оперирует с нереляционными объектами (массивы, списки и тд). Реляционной же модели никакой язык вообще не нужен . Кодд нам ничего по этому поводу не завещал, что вот "реляционанная модель...должна быть использована с такими-то непротиворечищами ей языками..." типа SQL, т.е ваши предположения по поводу "не противоречит" не совсем корректны. Вы и с помощью синтаксически правильных SQL-выражений можете пытаться ее нарушать, однако именно реляционная СУБД не позволит вам этого. Далее: вы можете изобрести и свой не-SQL язык, скажем с ОО возможностями (там наследование, полиморфизм и т.д) и к-рый будет у вас оперировать на реляционной модели. Почему бы нет\\r
\\r
Может я действительно ищу проблем, и надо действовать китайским народным методом реиспользования кода cut&paste, как описано здесь \\r
\\r
Да уж, таким китайским не стоит. Но проблемы искать, а еще хуже создавать тоже IMHO не следует даже если очень захотелось опробовать какую-нибудь заумную ИТ-штуковину, например, для самосовершенствования. Лучше еще раз усовершенствовать свое мышление, продумав и проиграв последствия в голове\\r
\\r
Но вопервых, дело в том что компания бурно развивается и нет времени на тщательное моделирование будущих процессов, есть потребность существующие учитывать уже вчера, а во-вторых, меня просто ломает такой подход, видимо надо переломатся ))) \\r
\\r
Мне ваша ситуация примерно ясна - очень типично для РФ. Кстати, я там говорил про какие-то возможные архитектурные варианты, но ведь есть и готовые решения, например, для документооборота или автоматизации ФХД. Этот вариант не рассматривали? Вообще разговаривать и что-то думать по поводу архитектуры вашей ИС (самодельной или покупной) можно серьезно только в случае, если вы расскажете хотя бы кратко о задачах , к-рые вам поставило руководство. Пока мне кажется, что вся инициатива исходит именно от вас. Нет? Просто так можно скатиться в яму абстрактных рассуждений "что лучше так, чем эдак" как в подскажите о выборе архитектуры для корпоративной информационной системы :о)