Case-средства в серьёзных проектах

← →
Курдль © (2006-09-18 14:19) [40]

> Игорь Шевченко © (18.09.06 13:28) [39]
> Понятно. Я из этих зверей Tiopf видел и еще несколько разных
> object-persistence frameworks. Все равно руками - оно надежнее :)

Но все равно перспектива заманчивая. Если ОСУБД достигнут необходимой надежности и производительности, мечта разработчиков "отвязаться от БД-реализаций" осуществится. А пока что приходится считаться с большинством требований "уровня технических служб".

Вот к тебе вопрос, как можно оперировать объектами предметной области во всех ипостасях?
Как заполнить, например, простейший табличный список некой сущности?
1. Добыть из БД записи, имеющие атрибуты этой сущности.
2. Создать объекты, по количеству выводимых экземпляров сущности.
3. Присвоить каждому объекту атрибуты, извлеченные из БД.
4. Как-то все это отобразить...

На мой взгляд, пока что наиболее удобный инструментарий для этого - ADO.NET. Считаю целесообразным создавать структуру БД, максимально приближенную к объектной концепции предметной области, а в программе использовать DataSet-ы ADO.NET, являющиеся отображениями объектов.

← →
Cyrax © (2006-09-18 17:14) [41]

Danilka © (18.09.06 11:10) [37]
На прошлой моей работе в БД было более 900 таблиц и вьюх более тысячи.
ErWin, вместе со своим Модельмартом, было достаточно гибок и удобен для совместной работы около 30-и человек.
Может что-то у кого-то с руками?

Ну да, конечно, с руками...
Задам только один вопрос: как имена таблиц и представлений то контролировали ?

← →
Курдль © (2006-09-18 17:39) [42]

> Cyrax © (18.09.06 17:14) [41]
> Задам только один вопрос: как имена таблиц и представлений
> то контролировали ?

Проблема имен не раскрыта! Какие проблемы могут создать имена таблиц и представлений?
Я не работал с ErWin-ом, но в PD что-то таких вопросов не возникало...

← →
Игорь Шевченко © (2006-09-18 17:43) [43]

Курдль © (18.09.06 14:19) [40]

> Вот к тебе вопрос, как можно оперировать объектами предметной
> области во всех ипостасях?
> Как заполнить, например, простейший табличный список некой
> сущности?

> На мой взгляд, пока что наиболее удобный инструментарий
> для этого - ADO.NET. Считаю целесообразным создавать структуру
> БД, максимально приближенную к объектной концепции предметной
> области, а в программе использовать DataSet-ы ADO.NET, являющиеся
> отображениями объектов.

Тоже вариант. Но это для .Net. А для не .Net можно все тоже самое или (поять же) вручную или с помощью какого-нибудь OPF

← →
ANB © (2006-09-18 17:51) [44]

Работал только с ервином и оракл-дизайнером.

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

ЗЫ. Надо бы как то нарисовать свой инструментик. Заодно зашить в него возможность апгрейда базы.

← →
Курдль © (2006-09-18 18:03) [45]

> ANB © (18.09.06 17:51) [44]
> Главное - четко разработать и потом соблюдать правила наименования.

А какие еще могут быть правила в наименовании, кроме наименования сущностей и атрибутов своими именами? Типа если сущность сделка, то и таблица DEALS, если атрибут дата сделки, то и поле DEAL_DATE?..
Или это касается индексов, и ключей?..

> ANB © (18.09.06 17:51) [44]
> ЗЫ. Надо бы как то нарисовать свой инструментик. Заодно
> зашить в него возможность апгрейда базы.

Точно! И продавать его за $100000, как Power Designer (в полной комплектации).

← →
ИА (2006-09-18 19:55) [46]

>Кто как считает, стоит ли применять Case-средства в серьёзных проектах...
Т.е. достаточно ли они развиты для таких проектов.

Из моего скромного опыта хорошо работает что-то типа BPWin _без связи_ с кодом или структурой базы, независимо.
UML диаграммы не получалось толково применить, кодогенерацию сложно правильно сделать а без нее смысла особого нет.

ErWin вещь замечательная, особенно макросы для генерации хр. процедур. Главное в использовании DB дизайнеров - _все_ делать через них. Кто ручками в базу полезет - то по этим ручкам рублем, рублем. Иначе быстро все десинхронизируется и толку будет только красивую распечатку на стену повесить, для начальников. Что, в прочем, во многих конторах вполне оправданное единственное применение для SADT, IDFX, UML и других важных акронимов.

← →
Cyrax © (2006-09-18 20:03) [47]

Курдль © (18.09.06 17:39) [42]
> Задам только один вопрос: как имена таблиц и представлений
> то контролировали ?
Проблема имен не раскрыта! Какие проблемы могут создать имена таблиц и представлений?
Я не работал с ErWin-ом, но в PD что-то таких вопросов не возникало...

А это вопрос к Danilka © (18.09.06 11:10) [37] - он то работал в ERWin...

← →
Danilka © (2006-09-19 08:58) [48]

[41] Cyrax © (18.09.06 17:14)
> Задам только один вопрос: как имена таблиц и представлений
> то контролировали ?

Не понял вопроса. Чего там контролировать-то? Имена надо давать, а не контролировать. :)
Была общепринятая практика давания имен. Например, вьюхи документов начинаются с vd$ХХХХ_..., где ХХХХ - код класса документа, вюьюхи регистров начинаются с vr$, табличные части документов имеют постфикс _sp, и т.д.
Кистати, ошибся я, вьюх было раза в 2-3 больше чем таблиц.

← →
Danilka © (2006-09-19 09:00) [49]

Кистати, была книжка внутрефирменная "Корпоративные стандарты", где были расписаны правила именования в т.ч. и констрейнов и индексов.

← →
Некто © (2006-09-19 09:35) [50]

> Danilka

Ты случайно не ТЭВИСе работаешь? :)

← →
Danilka © (2006-09-19 09:41) [51]

[50] Некто © (19.09.06 09:35)
Нет, но год-полтора назад там появлялся частенько. :)
Работал в Инфоладе, а ТЕВИС был одним из клиентов. Теперь там инфоладовская КИС, какраз та самая на тыщи въюх и таблиц. :)

← →
WondeRu at work (2006-09-19 09:49) [52]

Помню была у меня попытка нарисовать UML диаграммку классов в Visual Studio 2005. Проект был ASP.NET 2.0 сайт. Из-за того что HTML-код страницы и класс реализующий форму разделены, дизайнер глючил и не давал вытащить класс этой страницы или юзер-компонента. :(
Сак, короче!

← →
Курдль © (2006-09-19 10:16) [53]

> Danilka © (19.09.06 08:58) [48]
> Была общепринятая практика давания имен. Например, вьюхи
> документов начинаются с vd$ХХХХ_..., где ХХХХ - код класса
> документа, вюьюхи регистров начинаются с vr$, табличные
> части документов имеют постфикс _sp, и т.д.

МАМА!!! И чему ЭТО помогало? :)

← →
Danilka © (2006-09-19 10:22) [54]

[53] Курдль © (19.09.06 10:16)
Придумыванию осмысленных имен, например. :)
А как ты таблицы/въюди обзываешь?
Неужелит что-то типа: T102334?
:)

← →
Некто © (2006-09-19 10:36) [55]

> Danilka © (19.09.06 09:41) [51]

Я просто слыхал, что они какую-то супер-пупер биллинговую систему хотят. :)

← →
Курдль © (2006-09-19 10:56) [56]

> Danilka © (19.09.06 10:22) [54]
> А как ты таблицы/въюди обзываешь? Неужелит что-то типа: T102334?

Я таблицы называю, в соответствии с концепцией хранения данных проекта.
А также - в соответствии с типовыми правилами построения РСУБД.
Название сущности должно максимально соответствовать названию объекта предметной области (существительное в им.падеже ед.числе по-русски).
Когда создаешь концептуальную модель, так по-русски и пишешь:
СУБЪЕКТ
ПОЛЬЗОВАТЕЛЬ
СДЕЛКА
ДОКУМЕНТ
ДОГОВОР

Entity концептуальной модели в PD позволяет сопоставить наименованию сущности имя таблицы (существительное во мн.числе по-английски):
SUBJECTS
USERS
DEALS
DOCUMENTS
CONTRACTS

Атрибуты сущности также описываются простым словосочетанием и им присваиваются коды будущих полей таблиц
Идентификатор субъекта SUB_ID
Тип субъекта SUB_TYPE
и т.п.

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

Прежде чем начинать что-то проектировать, нехило семантическую модель накидать. А также внутрикомандное "соглашение о наименованиях".

[55] Некто © (19.09.06 10:36)
Шо, опять? :)

[56] Курдль © (19.09.06 10:56)
И что?
Там практически также.
Только существительное в ед.числе по-английски. :)
Базовая таблица для всех документов, содержит общие реквизиты такие как номер, дата, статус, класс, фирма и т.д. обзваецца как doc_general.
Наследник - договора обзывается как doc_contract. Наследник счет/ СФ: doc_invoice, наследник платежный документ, от которого наследуюцца кассовые одера, банк.платежи и т.д.: doc_payment.
Таблица контрагентов - cont, фирм - firm, номенклатура - nomencl и т.д.
И все в том-же духе.
Если бы ты был повнимательнее, то заметил, что в [48] я писал про именование вьюх.
ИХ намного больше, в первую очередь для документов - своя специфика. Кроме того, они собираются из кучи таблиц. Поэтому, для документов их оказалось проще обзывать так, как я написал.
Например, все счет-фатуры: vd$01007, имеющие неоплаченый остаток: vd$01007_rest и т.д.

> vd$01007, имеющие неоплаченый остаток: vd$01007_rest и т.
> д.

Ужасно.

[59] Ega23 © (19.09.06 11:17)
Это только так кажецца.
На деле достаточно удобно.
К тому-же, для какой-либо предметной области имеешь ограниченый набор док-тов, штук 7-10, код класса этих документов запоминаешь бысто.
Я уже почти год там не работаю, а основные классы помню.
Если надо узнать чья это вьюха - достаточно глянуть комментарий к ней.
Вытащить из базы код класса необходимого документа - написать запрос, выполнить и узнать, работы на 15 секунд.

> К тому-же, для какой-либо предметной области имеешь ограниченый
> набор док-тов, штук 7-10, код класса этих документов запоминаешь
> бысто.

Ну если так, что ещё ничего. Я просто подумал, что если есть 1007б то есть и остальные 1006... :о)

> Danilka © (19.09.06 11:12) [58]
> как doc_general.
> Наследник - договора обзывается как doc_contract. Наследник
> счет/ СФ: doc_invoice, наследник платежный документ, от
> которого наследуюцца кассовые одера, банк.платежи и т.д.
> : doc_payment.

В принципе, нормальная практика именования. Но для моего варианта используемого ПО, это не очень приятно. Например, PD многие свои объекты именует с помощи конкатенации начальных букв сущностей (таблиц и т.п.).
Потом их легко идентифицировать и, например, переименовать.
В твоем случае сгенерированный форинкей связи doc_general и doc_contract выглядел бы навскидку так: FK_REL_DOC__DOC_ :)
Кроме того, средства отладки SQL-запросов представляют удобные средства типа автоподстановки. Здесь бы пришлось надолбить doc_g, чтобы напечаталось "doc_general"
В общем, проблем бы прибавилось.

[61] Ega23 © (19.09.06 11:47)
> Я просто подумал, что если есть 1007б то есть и остальные
> 1006... :о)

Увы. :(
А знак доллара вначале говорит о том, что система шеснадцатеричная, то-есть, на самом деле можно продолжить взад так: 1006, 1005, 1004, 1003, 1002, 1001, 1000, 0FFF ...

Шютк! :)
На самом деле, изначально никакого контроля не было, поэтому номера классам раздавали как угодно, например, есть и 50000. :)
Ну, 1006 правда и на самом деле есть. :)

[62] Курдль © (19.09.06 11:47)
> В твоем случае сгенерированный форинкей связи doc_general
> и doc_contract выглядел бы навскидку так: FK_REL_DOC__DOC_
> :)

Шо правда, то правда, FK приходицца ручками переправлять, по поводу doc_g не особо страшно, т.к. я в запросах всегда алиасы таблиццам даю, например, для doc_general - g. :)

Case-средства в серьёзных проектах Найти похожие ветки