2 vdimas: \\r
Но вот, мучит меня в последние годы раздвоение личности. \\r
Когда проектирую БД - применяю одни понятия. \\r
Когда ту же предметную область разрабатываю на C++ - совершенно другие. \\r
\\r
Это закономерное следствие используемых вами да и не только вами одновременно разных парадигм/подходов/моделей/языков для описания предметной проблемы\\r
\\r
Прошу обратить внимание, естественное для удобного ООП программирования представление не оперирует ключами (всякими ID или составными ключами), объекты просто ссылаются в памяти друг на друга. \\r
\\r
Собственно это полезная естественная возмость ОО языка или модели. У реляционной модели свои (другие) полезные возможности как и у языка запросов типа SQL. Следует учесть, что все определялось кругом задач и возможностями, к-рые были исторически заложены в ту или иную технологию, т.е РМ - это 70-е годы, а ООАП и ООП - это конец 80-90-е годы\\r
\\r
При таком подходе, любая самая навороченная бизнес логика превращается в детский лепет даже на C++. \\r
\\r
Вы не путаете бизнес-логику (business logic) с моделью предметной области (stakeholder\\\'s view / universe of discourse)? Это разные вещи. Бизнес-логика (БЛ) - некий набор правил или регламентов бизнес-процессов, к-рый "подразумевает" предметную область, т.е это может быть больше, чем ее модель, которая представляет лишь точки зрения бизнес-пользователей на структуру и поведение данных. Вот простая аналогия, например, уже в реализации: модель данных (реляционная), описывающая предметную область -И- набор любых инструкцй DDL, реализующих БЛ на множестве реляционных объектов (таблицы, домены и т.д).\\r
Конечно, сложно придумать такую предметную проблему (бизнес-логика + предметная область), чтобы ее было невозможно смоделирвать/описать с помощью ОО-подхода (ООАП/UML, C++ и т.д). Однако даже БЛ может быть настолько сложной, что могучие и удобные возможности С++ покажутся просто жалкими. Следует еще учесть, что конечная цель разработчиков - это не моделирование или описание предметной проблемы на чем-то, а создание приложения , которое будет не только адекватно что-то отражать (предметную область или БЛ), но еще и будет качественным , т.е быстрым, надежным, удобным и т.д и т.п\\r
К сожалению явных и внятных определений предметной области я не нашел, но вот несколько определений БЛ или бизнес-правил:\\r
\\r
business rules (Microsoft / MSDN Glossary)\\r
The laws, regulations, policies, and procedures that are encoded into\\r
a computer system. Also known as business logic .\\r
-or-\\r
The combination of validation edits, logon verifications, database lookups,\\r
policies, and algorithmic transformations that constitute an enterprise\\\'s\\r
way of doing business. Also known as business logic.\\r
\\r
business rule (Rational / RUP Glossary)\\r
A declaration of policy or condition that must be satisfied within\\r
the business.\\r
\\r
business logic (IBM / WebSphere Glossary)\\r
The codified procedures in a business software system that implements\\r
an organization’s day-to-day operations (such as processing an order,\\r
payroll management, and so on).\\r
Business logic typically includes industry-standard procedures\\r
for business operations and customizations reflecting an organization’s\\r
unique business policies.\\r
\\r
business logic (Sun / J2EE Glossary)\\r
The code that implements the functionality of an application. In the\\r
Enterprise JavaBeans model, this logic is implemented by the methods\\r
of an enterprise bean.\\r
business method \\r
A method of an enterprise bean that implements the business logic\\r
or rules of an application.\\r
\\r
А если проектировать по-старому, отталкиваясь именно от структуры DB, то клиент оперирует разве что такими понятиями, как рекордсет, поля и пр. \\r
Т.е. безо всякой типизации и намека на ООП.\\r
...\\r
Как это хранить по-человечески в базе? Перепробовал кучу способов. .... \\r
\\r
Как уже писал "Cat2" вас волнует неидеальность "инструментов" для описания предметной области. Она многих "волнует" и смущает, но главное чтобы она не мешала грамотному проектированию. Проектировать приложение от данных неправильно , а поэтому я бы вам не советовал доверять "Cat2" на слово, т.к он явный апологет проектирования "от данных". Для разработки даже самых сложных бизнес-приложений ООАП подход, во-первых, уже доказал свою большую эффективность по сравнению со структурным подходом, а, во-вторых, опускаться до структурного подхода да и еще неправильного ("от данных") сегодня просто неоправданно, неэффективно и чревато последствиями. Модель данных (реляционная/ОО) должна закономерно получаться в процессе проектирования, т.е из системных вариантов использования (system use case/SUC), если вы используете ООАП, например, тот же урезанный RUP. Принимать решение, какой тип архитектуры или платформу выбирать можно только после того как вы соберете нефункциональные требования и получите модель проектирования (design model)\\r
\\r
Как связать типизацию и графоподобную структуру ООП объектов с плоскими таблицами? \\r
\\r
Прочтите пару-тройку полезных и неглупых книжек на эту тему, например (тем более стоят они почти копейки):\\r
\\r
Лешек А. Мацяшек. Анализ требований и проектирование систем.\\r
Разработка информационных систем с использованием UML. \\r
– М.: «Вильямс», 2002. – 432 с. (ISBN 5-845-90276-2, м/о, цена: 256 р.)\\r
- отличная и общая книжка по архитектуре, системному проектированию и ОО-подходу,\\r
но те же недостатки, что и у Лармана \\r

Ларман К. Применение UML и шаблонов проектирования.\\r
(Введение в объектно-ориентированный анализ и проектирование). \\r
– М.: «Вильямс», 2002. – 624 с. (ISBN: 5-845-90250-9, т/о, цена: 236 р.)\\r
- отличная книжка по архитектурным шаблонам, использованию MVC/4+1, моделированию\\r
предметной области, хотя и криво переведена, а автор типичный программист и несколько\\r
лось по части получения требований и построению модели SUC \\r

Нейбург Э., Максимчук Р. Проектирование баз данных с помощью UML. \\r
– М.: «Вильямс», 2002. – 288 с. (ISBN: 5-8459-0355-6, м/о, цена: 150 р.)\\r
- отличная книжка, название говорит за себя, подробно рассматривается бизнес-моделирование,\\r
переход от BUC и SUC к архитектуре, есть примеры, хотя и криво переведена \\r

Роберт Дж. Мюллер. Базы данных и UML. Проектирование. \\r
– М.: «Лори», 2002. – 420 с. (ISBN: 5-85582-168-4, м/о, цена: 328 р.)\\r
- дороговата, хотя то же, что и книга Нейбурга-Максимчука, но более богата примерами \\r

Антон Элиенс. Принципы объектно-ориентированной разработки программ. \\r
– М.: «Вильямс», 2002. – 496 с. (ISBN: 5-8459-0233-9, т/о, Цена: 169 р.)\\r
- отлично рассказывается про достоинтсва/недостатки ОО-языков/подходов, дается\\r
их сравнение со структурными, но автор явно отстал от жизни по части бизнес-анализа \\r
\\r
((я также планирую выложиь полный список полезной лит-ры по ООАП и проектированию ПО с кратким обзором в топик Обсуждение и Вопросы по ОБЪЕКТНО-ОРИЕНТИРОВАННЫМ МЕТОДАМ (ООАП / OOAD) и UML)) Просто не хочется рассказывать лекцию, когда есть уже написанные книжки. Попробуйте также поискать в Инете по следующим ключевым словам и их комбинациям: data, aware, database, class, recordset, connection. И найдете множество статей и примеров кода на VB и С++, например, на том же www.planet-source-code.com в разделе Databases/ Data Access/ DAO/ ADO или Object Oriented Programming (OOP) \\r
\\r
Да, нам предрекают тут во всяких манифестах светлое иерархическое будущее взамен реляционного настоящего... \\r
А сейчас-то что делать? \\r
\\r
Много чего нам обещали, обещают и будут обещать те, кому это нужно - обещать. Такая уж задача у зазывал. Задача же грамотного разработчика - использовать самые лучшие и доступные ему инструменты для того чтобы вести грамотную и по возможности эффективную разработку с помощью современных и проверенных на сегодня ИТ-технологий\\r
\\r
Это после того как я столько времени приучался не думать на SQL а заставлял себя думать на ООП? \\r
\\r
Я бы так перефразировал "Cat2":\\r
Мой главный совет: Прекратите думать на С++, когда пишете на SQL! И не думайте на SQL, когда пишете на C++! \\r
И еще: не думайте объектно, когда работаете с реляционной моделью, а также не думайте реляционно, когда работаете с ОО моделью. \\r
\\r
Беда в том, что большинство современных БД приложений, мягко говоря, слабоваты. Полностью красиво запихнуть логику на сервер БД не получается (я использую MS SQL, оракловцам чуть легче). Так что прилично приходится набрасывать кода на клиенте или сервере приложений. \\r
\\r
Еще легче тем, кто работает с Cache\\\'. Однако, когда дело доходит до репликации или других естественных вещей, к-рые встроены в распространенные реляционные СУБД, но к-рых нет у Cache\\\' возникают трудности. Этот топик вы, конечно, читали: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД\\r
\\r
1. Entity engin - использует БД как просто место хранения состояний объектов. О таких вещах, как ограничение целостности, речь не идет. Мощь встроенных инструментов БД практически не используется. Зато очень удобно проектировать бизнесс-логику произвольного уровня сложности. \\r
\\r
А что такое "Entity engin" по сути? К своему, наверное, стыду много раз слышал этот термин, но не представляю, что это такое. И почему там "очень удобно проектировать бизнесс-логику произвольного уровня сложности"? Кстати, на чем там ее проектируют?\\r
\\r
3. Смешанный тип - часто используется в 3-х звенке. Что удобно вычислять на сервере БД - вычисляют на БД, что не удобно - то на сервере приложений. .... \\r
\\r
Пожалуй это (т.е 3-звенный и выше) эффективный тип архитектуры для построения больших, распределенных и масштабируемых приложений и Майкрософт тут не причем. Это как бы мнение (объективное) признаных авторитетов в программной инженерии и в проектирования архитектуры, например, тех же Ф.Кратчена и Г.Буча. Однако, следует опять руководствоваться здравым смыслом. Немного обсуждения есть в топике С чего начать изучение трехзвенки ? и Унифицированные методы - общий вопрос построения. Проблемы авторов топиков в чем-то схожи с вашей\\r
\\r
В жертву приносятся драгоценные часы работы разработчика, корпящего над очередным велосипедом. Фигня вся эта "бизнес-логика", ненавижу! Хочу тратить на ЭТО как можно меньше времени. ..... \\r
\\r
Это для вас она фигня (и может это правильно), а для заказчика это вовсе не фигня. И потом, если вы - программист, то какого лешего вы занимаетесь получением требований и моделированием предметной области тем более мысля при этом как программист? Вообще это задача аналитика(-проектировщика) , если все делать по уму, а не через Ж. Программист должен писать код уже по готовой спецификации, например, той же архитектуры

2 vdimas: \r
Скажем так, реализация специфированных бизнес логикой правил, алгоритмов, ... превращается в детский лепет, ессно саму бизнесс-логику никто не упрощает, ибо это то, что дано "свыше". \r
\r
Нет, я тоже неправильно выразился. Попробуем так: С++ пожалуй сегодня будет уже не самым удобным и эффективным языком/средством по сравнению со средствами, к-рые уже ближе к 4GL, а посравнению с интегрированными средствами разработки (например, какой-нибудь X++ или ABAP), ориентированными на конкретную бизнес-среду он будет вообще очень неудобным и неэффективным. При этом я нисколько не умаляю очевидных возможностей С++ просто дело в условиях, к-рые сегодея поставлены перед разработчиком\r
\r
В условиях небольшой (но, поверьте, весьма эффективной) команды, само такое частое переключение дорогого стоит. Ибо, для того, чтобы полностью и качественно сосредоточиться на другом подходе, порой требуются дни (!!! подозреваю, что найдутся остряки на эту фразу, ну да бог с ними), ибо практически надо стать другим человеком. Когда делаешь это часто - элементарно больше устаешь, чем в ситуации когда ничто не мешает тебе сосредоточиться на чем-то одном. \r
\r
Согласен. Вы далеко не первый, кто это утверждает. Хотя я как-то взял себе моду (может дурацкую?) утверждать, что это полезно для мозгов и развивает гибкость мышления - периодически переключаться с ОО на реляционную модель и наоборот. Не знаю, вспоминая свою фрилансерную вольную молодость (96-99 гг), когда ежедневно писал то на VС++, то на TSQL, то проектировал модель данных, то - классы с GUI. Как-то нормально было, основная проблема была в другом - найти того, кто предложит проект по-серьезнее с большими деньгами. Не знаю, может все дело в конкретном человеке? :о)\r
\r
Т.е. мысль такова - если бы удалось ПОЛНОСТЬЮ реализовать все приложение в рамках одного подхода - моя работа могла быть намного эффективнее (у меня свои мерки эффективности, так что просьба остряков не беспокоиться). \r
\r
Это не так просто. Придется либо переходить на средство более близкое к 4GL, не пользоваться же каким-нибудь убогим гибридом типа ESQL/C. Вы на C++ пишете, а это вообще адский труд (сам знаю). Переходите уж на Delphi 7 или PowerBuilder9. IMHO их возможности и преимущества очевидны. Хотя, конечно, стоят они недешево\r
\r
Задача еngine - автоматизировать "подводную часть айсберга", т.е. автоматически формировать запросы на обновление или выборку данных. Этот engine оперирует с объектами и базой, опираясь на некоторые знания об самих объектах и о том, как эти объекты в базе храняться, т.е. такой подход подразумевает наличие некой мета-информации обо всем этом. .... \r
\r
Под этим имелся в виду просто промежуточный "слой" в РСУБД, к-рый обсуждался в Объектно-ориентированная система управления реляциоными базами данных или здесь или что-то более "интеллектуальное" наподобии UDDI/ebXML (или что-то наподобии управления знаниями (KM) хотя это наврядли), когда не знаешь "кто" и "как" предоставляет сервис/хранит данные, но знаешь только "что" хочется от него и "какие" данные нужнны?\r
\r
Во-вторых, проектируют просто иерархию классов, не особо заботясь (вернее, специально не заботясь) о таком моменте, как связка ОО модель - Рел. модель. \r
Очень удобно. Правда, в ущерб эффективности и т.д. (повторяюсь) \r
\r
Cпасибо, я понял идею. Просто я думал, что есть какие-то серьезные коммерческие продукты, снабженные удобными средствами проектирования. Т.е они есть и я знаю пару-тройку таких что-то типа визуального конструктора (пост от Дата: 5 дек 02, 19:56), к-рый позволяет конструировать бизнес-операции и бизнес-объекты, к-рые потом отображаются, например, в объекты Cache\' и проект Delphi соответственно, но я не уверен, что это именно средства как в категории продуктов "Entity enginе" или нет?\r
\r
Дело в том, что помимо "прямого" кодирования алгоритмов по спецификации, приходиться выполнять еще массу "ритуальных приседаний" по общению с БД. Разумеется этот процесс обычно автоматизируется по-макимуму, используя максимум возможностей ООП-языков. И все же, все же.. \r
\r
Не совсем понял, что именно имеется в виду. Ведь есть же классы соединений (см. ссылки в моем предыдущем посте выше), есть архитектурные шаблоны. В книжках, посвященных Delphi & VB БД-приложениям это все описано как должно "жить" соединение в приложении. Можно пообсуждать конкретные архитектурные вопросы про соединения и, например, без привязки к конкретному ОО языку\r
\r
Ой как спорно... Кто-нибудь видел живьем ГРАМОТНОГО проектировщика? Я видел много разных, грамотных еще не видел. \r
\r
Не хочу показаться нескромным, но я видел и вижу постоянно, например, когда пиво с ними выпиваю. Я лично знаю нескольких людей в г.Москва, которые мыслят основательно именно как системные аналитики и проектировщики. Себя я из скромности не упомянаю. Хотя в смысле уровня все, конечно, относительно . Я, например, полный нуль по части RT-систем (очень перспективный рынок труда для проектировщиков в России и в США, кстати, на к-рый мне, например, только слюни остается пускать!), т.е какие-то общие знания есть, но не более; также и по части J2EE/CORBA с трудом представляю как там вся эта связка фурычит. Получается, что я уже неграмотный или какой-то "узкий" что ли? Не думаю. Просто моя специализация - это "ширпотребовская" платформа Windows/Office с MSSQL/Access, IIS/BizTalk/CS, ActiveX/COM/Net и т.д все, что с ними связано. Но все задачи решаю именно инженерным образом, а не кустарным. Да, иногда приходится кое-что делать не совсем грамотно, интуитивно, т.к время и человеческие ресурсы бывает ограничены и даже попустительствовать заказчику в его явных глупостях. Главное чтобы генеральная линия оставалась верной. Вот и делайте выводы "ху из ху", как говорится :о)\r
\r
.. Хороший программист только тогда и является хорошим программистом, если он еще и проектировщик нехилый. Время "кодеров" уже уходит. \r
\r
Если объективно, то вы ошибаетесь насчет кодеров. Возможно вы судите по России или по Rentacoder.com c Sourceforge.net. Но на Западе (я не беру в расчет конторы где <20 человек) да и в крупных российских компаниях уже давно поняли и приняли инженерный подход , т.е отделили роли программистов от проектировщиков с аналитиками. Более того даже люди и департаменты разные, чтобы одни не воздействовали на других. Что же касается программиста - его задача программировать , а не проектировать или рисовать модель GUI. Однако, я согласен, что программист должен иметь однозначное с проектировщиком понимание общих для них вещей: методологические принципы, нотация для моделирования, специфика платформы и т.д\r
\r
.. Знаю несколько хороших программистов, которые заткнут за пояс очень много проектировщиков на их же "поле". \r
\r
Почему бы и нет, если те проектировщики были неграмотными или неопытными? На таких не стоит равняться. Я знаю проектировщиков, к-рые заткнут за пояс любого молодого и даже грамотного программиста. Это я к тому, что я тоже бывший программер\r
\r
.. А вообще уже есть интерес и дальше общаться. После 15-го (выкладка беты), обязательно просмотрю эти книжки, дабы войти в "форму", и надеюсь еще не раз "скрестим шпажки". \r
\r
Почему бы и нет? Я всегда готов к дуэли лишь восторжествовала объективная истина и кому-то это пошло на пользу. Если будет время, то прочтите на досуге топики (просто легкое чтение) по теме разделения труда и специализации: Перспективы свободных художников в Москве (стр.2-4) и Все мы чего-то автоматизируем. Желаю успехов в сдаче беты! :о)

2 U-gene: \\r
Категорически протестую!!!, Объектно-ориентированную систему управления реляциоными базами данных не надо расматривать только как промежуточный слой! \\r
\\r
Просто ради справедливости: я по-мойму и не заикался даже, что ООСУРБД - это только промежуточный слой или что он якобы такой же "убогий" по функциональности как, например, Тенцера. Так при чем здесь "Беда-беда" и т.д?\\r
\\r
То есть конечно он будет реализован как промежуточный слой, но в результате мы получим среду, которая на стороне сервера \\r
\\r
Собственно это я и утверждал, не более\\r
\\r
1)позволяет полностью(! не хуже чем...ну ... усредненный ОО язык из современных...) описывать моделируемую предметной область \\r
\\r
Просто ради ясности ИТ-языка лучше сказать так: "предоставляет возможности для полного описания предметной области (почти любой сложности)" потому что сама по себе ООСУРБД не позволяет или не определяет полноту. Ее определяет тот, кто выполняет моделирование\\r
\\r
3)позволяет организовать доступ (в том числе групповой) к этим объектам данных ....и к данным этих объектов :) \\r
(....и никаких классов соединений в этом описании в принципе присутсвовать не будет) \\r
\\r
Я думаю, что "vdimas" уже понял это и оценил перспективные возможности ООСУРБД :о)\\r
\\r
И потом. Ну почему же так категорично "Проектировать приложение от данных неправильно". Почему бы не сказать, что "Проектировать приложение только от данных неправильно". \\r
\\r
Хм, ну если проектировать приложение от данных неправильно, то проектировать приложение только от данных тем более неправильно. Имелось в виду именно проектирование приложения в целом , а не БД. При создании приложения, например, на этапе сбора и анализа требований (функциональных или UC) отталкиваются прежде всего от того "ЧТО ДЕЛАТЬ" приложению, а не "ЧТО ХРАНИТЬ" или какими данными будет оперировать приложение. Конечно, анализ предметной области ("ЧТО ХРАНИТЬ") никуда не исчезает и имеет такое же важное значение. То же самое и на этапе проектирования: статическая модель данных точно также важна. При этом не важно используются структурный или ОО подходы, т.е именно такая приоритетность функциональности над данными более правильная (корректная и т.д). Вот что имелось в виду под "проектировать приложение от данных неправильно". Кстати, неправильно и проектировать приложение от пользовательского интерфейса хотя учитывать и проектировать его также необходимо\\r
\\r
... В связи с этим, хочу задать вопрос. Когда вы будете проектировать, ну скажем, класс "Поставка", этот класс в том или ином виде будет содержать заголовок поставки(номер,дата) и данные о элементах поставки(артикул, штуки), представленных в виде массива (или набора или что-то еще повторяющееся) структур (или объектов или чего-то еще). И вряд ли Вы поместите данные о заголовке (например "дата поставки") рядом с артикулом. Скажите, почему Вы так сделаете? \\r
\\r
Есть (а) проектирование всего приложения, а есть (б) моделирование данных или проектирование БД. (б) - это подзадача (а), в к-рой используются свои подходы и технологии, ориентированные на решение именно этой подзадачи. А поскольку ваш вопрос относится к подзадаче (б), то и решается он соответсвенно более "узкими" методами (анализ зависимостей, избыточности, нормализацией, денормализацией и т.д)\\r
\\r
.. Грамотный анализ предметной области, ее правильное описание в виде наборов взаимосвязанных классов и представление в виде набора взаимосвязанных объектов - это святое. Но ведь снизу то у нас некая есть система хранения данных. \\r
\\r
C этим никто и не спорит! Подзадачу анализа и моделирования предметной области с проектированием БД также надо решать грамотно и полно