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

← →
Cyrax © (2006-09-15 12:48) [0]

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

← →
Sergey13 © (2006-09-15 12:53) [1]

Я бы сказал, стоит ли в НЕ серьезных. Десяток таблиц нарисовать и ручками не проблема. А вот с сотнями тяжело все в голове держать.

← →
Ega23 © (2006-09-15 13:00) [2]

Если ты 100 или 300 таблиц можешь удержать в голове - флаг тебе в руки.
Я на систему где больше 5 таблиц - обязательно пользуюсь.

← →
Cyrax © (2006-09-15 13:04) [3]

Ну, в разработке больших баз данных, Case-средства, конечно, сильно помогут. Но базами данных они не ограничиваются.
(моделирование бизнес-процессов, структур данных, поведения, кодогенерация)

← →
vidiv © (2006-09-15 13:25) [4]

Еще одно умное слово для развода клиентов-лохов

← →
Ega23 © (2006-09-15 13:32) [5]

> (моделирование бизнес-процессов, структур данных, поведения,
> кодогенерация)

Моё ИМХО - для небольших проектов это просто нерентабельно. Если ты всю бизнез-схему проекта можешь в голове уместить, то использование CASE-средств для этого - просто трата драгоценного времени.

← →
Курдль © (2006-09-15 16:22) [6]

А я не могу понять, как можно даже в маленьком проекте обойтись, например, без модели данных? Вручную писать скрипты? Умудриться не забыть ни одного форинкея или констрэйнта? 8-()
А не проекте, где больше 2-х человек, общаться-то как, если без терминологии ERWin или UML? Типа "эта табличка имеет первичный ключ, а эта - имеет поле, сцылающееся на нее"?

← →
Ega23 © (2006-09-15 16:25) [7]

> А я не могу понять, как можно даже в маленьком проекте обойтись,
> например, без модели данных? Вручную писать скрипты? Умудриться
> не забыть ни одного форинкея или констрэйнта? 8-()

Ну 5 таблиц я и без всяких дизайнеров вручную накидаю. А вот на 10 - уже обязательно в PowerDisigner модель данных нарисую.

← →
Курдль © (2006-09-15 16:29) [8]

> Ega23 © (15.09.06 16:25) [7]
> Ну 5 таблиц я и без всяких дизайнеров вручную накидаю. А
> вот на 10 - уже обязательно в PowerDisigner модель данных
> нарисую.

А я и на 5 поленюсь делать вручную. У PowerDisigner-а мозги большие - пусть они и думают!
Однако, у меня 5 таблиц никогда не получается :(
Вроде сначала кажется, что их 5, а начнешь реализовывать, наследовать, ассоциировать - 50!

← →
Ega23 © (2006-09-15 16:32) [9]

> Однако, у меня 5 таблиц никогда не получается :(

Ну для курсовых работ в качестве DataStorage - хватает и пяти. Для более серьёзного - меньше 30 никогда не получалось, если нормально нормализовать (уж простите за тавтологию).

← →
Карелин Артем © (2006-09-15 16:39) [10]

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

← →
Ega23 © (2006-09-15 16:47) [11]

> У нас сотня таблиц и полтысячи хранимых процедур на сиквеле.

Сто таблиц? Без графического представления? При работе в команде?
Ну не знаю, не знаю...

← →
Danilka © (2006-09-15 16:48) [12]

[10] Карелин Артем © (15.09.06 16:39)
> У нас сотня таблиц и полтысячи хранимых процедур на сиквеле.
> Никаких CASE не используем, все вручную творим

ужос

> встроенные средства для построения диаграмм с 2005 сиквеле
> дают все необходимое.

ужос2.
попробуй для этого Erwin, хотя-бы несколько схем, потом подсядешь однозначно.
начинаешь думать такими схемами, а рисовать в Ервине их намного удобнее, чем в SQL Server Management Studio.

← →
Danilka © (2006-09-15 16:49) [13]

[10] Карелин Артем © (15.09.06 16:39)
Кистати, для командной работы в Ервине есть МодельМарт с разграничением доступа, локированием схем, когда кто-то один правит что-то и т.д.

← →
Некто © (2006-09-15 16:50) [14]

> При работе в команде?

Вот они где... телепаты. :)

← →
Курдль © (2006-09-15 16:50) [15]

> Ega23 © (15.09.06 16:47) [11]
> Сто таблиц? Без графического представления? При работе в
> команде?
> Ну не знаю, не знаю...

Да уж... Я тоже не знаю...
Одна кнопка F4 в PD чего стОит! Да и коллективный доступ к моделям данных с контролем версий он же обеспечивает! Какое еще средство позволит детально сравнить 2 модели?

← →
Игорь Шевченко © (2006-09-15 16:51) [16]

Ega23 © (15.09.06 16:47) [11]

А ты 100 таблиц в графическом представлении как смотришь ? Под микроскопом ?

← →
Danilka © (2006-09-15 16:53) [17]

[16] Игорь Шевченко © (15.09.06 16:51)
Сколько надо, столько и делаешь областей и моделей, каждая из которых на 10-20 таблиц и помещается на А4.
В чем проблема?

← →
Ega23 © (2006-09-15 16:54) [18]

> А ты 100 таблиц в графическом представлении как смотришь
> ? Под микроскопом ?

Ну там их по логическим кускам сгруппировать можно, цветом разделить.
Естественно, что не в одной куче. Комментарии, опять же расставить. Как в Visio, короче.

← →
Stakan © (2006-09-15 16:54) [19]

Игорь Шевченко © (15.09.06 16:51) [16]
Для этих целей служат Subject Areas

← →
Курдль © (2006-09-15 16:55) [20]

> Игорь Шевченко © (15.09.06 16:51) [16]
> Ega23 © (15.09.06 16:47) [11]
> А ты 100 таблиц в графическом представлении как смотришь
> ? Под микроскопом ?

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

← →
Игорь Шевченко © (2006-09-15 16:57) [21]

Так эта...руками посмотреть те же сгруппированные таблицы тоже можно. Без case-средства всякого...

← →
TohaNik © (2006-09-15 17:00) [22]

Пользуюсь, 1 раз.
Если приложение на сопровождении и не дорабатывается, то возле сервера с БД, схему вешаю.

← →
Курдль © (2006-09-15 17:00) [23]

> Игорь Шевченко © (15.09.06 16:57) [21]
> Так эта...руками посмотреть те же сгруппированные таблицы
> тоже можно. Без case-средства всякого...

Я сам предпочитаю и сотрудников пытаюсь научить мыслить графическими образами. Как им на SQL-скрипте объяснить, что Сущность ЮЗЕРЫ унаследована от сущности ГУМАНОИДЫ, унаследованной от сущности СУБЪЕКТЫ только по первичным ключам, но mutually exclusive children?

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

Курдль © (15.09.06 17:00) [23]

Может оно и хорошо, я ж не спорю. Просто в моей практике первичны классы предметной области, а уже во вторую очередь - средства их хранения. А в классах оно проще наследование объяснять :)

← →
Ega23 © (2006-09-15 17:10) [25]

> Может оно и хорошо, я ж не спорю. Просто в моей практике
> первичны классы предметной области, а уже во вторую очередь
> - средства их хранения. А в классах оно проще наследование
> объяснять :)

Пардон, а дерево классов ты тоже полностью в голове держишь, или таки рисуешь дерево?

← →
Курдль © (2006-09-15 17:13) [26]

> Игорь Шевченко © (15.09.06 17:04) [24]
> Может оно и хорошо, я ж не спорю. Просто в моей практике
> первичны классы предметной области, а уже во вторую очередь
> - средства их хранения. А в классах оно проще наследование
> объяснять :)

О! Переходи на ODMG!
Я пробовал - завораживает! Когда перед объявлением класса прямо в коде программы пишешь атрибут [persistent], и после создания экземпляра, тот начинает "жить" в БД. Нет никаких релэйшнов - есть коллекции и т.п. Чудо!

← →
MsGuns © (2006-09-15 17:33) [27]

извращенцы ;)

← →
Cyrax © (2006-09-15 17:37) [28]

Использовать Case-средства для моделирования БД, конечно, удобно. Можно будет не в одной СУБД базу сгенерировать. Да и легче саму базу разрабатывать.
Единственная проблема - это средство должно обеспечивать требуемую функциональность и гибкость.
Насчёт ERWin"а. Недостаточно гибкое средство, в чём я убедился на примере БД из 20-30 таблиц. Хотя функциональности вполне хватило...

Что касается моделирования бизнес-процессов предметной области, то особых требований к Case-средствам в этом плане не предъявляется, если они не имеют дело с кодом или базой данных.

← →
Cyrax © (2006-09-15 17:48) [29]

Сомневаюсь, что и с UML проблем не будет...

← →
vidiv © (2006-09-15 17:52) [30]

> PowerDisigner

Поделитесь пожалуйста
vid (песик) sakhgu.sakhalin.ru

← →
Курдль © (2006-09-15 17:58) [31]

> Cyrax © (15.09.06 17:48) [29]
> Сомневаюсь, что и с UML проблем не будет...

А какие могут быть проблемы с языком моделирования?

У меня, например, с Power Designer-ом проблем и не бывает.
Все, что касается концептуальных и физических моделей, создания скриптов БД, выявления ошибок и т.п. - вопросов не возникает.
Диаграммы ООП и архитектуры я глубоко не копал. Моим потребностям они удовлетворяют. Пробовал из диаграммы классов создавать готовые коды на C#. Решил, что забавно. Но смелости и знаний, чтобы юзать на полную в этом контексте не хватает :(

← →
Cyrax © (2006-09-15 18:21) [32]

Курдль © (15.09.06 17:58) [31]
А какие могут быть проблемы с языком моделирования?

Да какие-угодно. И гибкость, и функциональность, и ещё может что-то. Главное - чтобы минимизировать работу по исправлению и корректировке на физическом уровне.

Кто-нибудь работал с RationalRose ?
Хотелось бы сравнить с другими продуктами, реализующими UML...

← →
Sam Stone © (2006-09-15 21:11) [33]

В 2001 розе коряво работает с пачкой стрелок в диаграмме активности или как их там... с весны все уже забыл. В общем не особо роза понравилась (в визуальной части). Может быть потому что ее так усиленно нам впендюривали на лабах :) И с ХП она не очень дружит.

← →
Sergey Masloff (2006-09-15 23:21) [34]

Вобщем как всегда - можно и так и сяк. Я руками скрипт в 2 раза быстрее напишу чем любой дизайнер сгенерит, а вот потом бывает удобно конечно посмотреть в ERWin-е. Кроме того ервиновский скриптовый язык очень помогает при написании типовых триггеров (история там, тиражирование нестандартное...). Так что оба подхода уместны и сочетаемы.

С RationalRose я немного работал лет 5 назад. Остались не лучшие воспоминания о монстре.

← →
Суслик © (2006-09-16 00:31) [35]

для любого нормально case нужен внедренец - сам не внедришь (или будешь думать, что внедрил), нужен консультант.

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

Ega23 © (15.09.06 17:10) [25]

> Пардон, а дерево классов ты тоже полностью в голове держишь,
> или таки рисуешь дерево?

Человек удерживает в голове 5+-2 сущности. Дерево классов больше не бывает, а если бывает, то его надо выкидывать и перепроектировать.

Курдль © (15.09.06 17:13) [26]

> О! Переходи на ODMG!

Что за зверь, где можно познакомиться ?

← →
Danilka © (2006-09-18 11:10) [37]

[28] Cyrax © (15.09.06 17:37)
> Насчёт ERWin"а. Недостаточно гибкое средство, в чём я убедился
> на примере БД из 20-30 таблиц.

На прошлой моей работе в БД было более 900 таблиц и вьюх более тысячи.
ErWin, вместе со своим Модельмартом, было достаточно гибок и удобен для совместной работы около 30-и человек.
Может что-то у кого-то с руками?

← →
Курдль © (2006-09-18 11:21) [38]

> Игорь Шевченко © (18.09.06 11:00) [36]
> > О! Переходи на ODMG!
> Что за зверь, где можно познакомиться ?

Это стандарт. Прочитать можно в книге "Обработка объектных баз данных в C++. Программирование с использованием стандарта ODMG Автор(ы): Дэвид Джордан; "
А из живых баз я отдаленно видел Cache и немного потыркался с Versant-ом (это последний интегрирован со средой VS).

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

Курдль © (18.09.06 11:21) [38]

Понятно. Я из этих зверей Tiopf видел и еще несколько разных object-persistence frameworks. Все равно руками - оно надежнее :)

← →
Курдль © (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]

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

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

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

> 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 и других важных акронимов.

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

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

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

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

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

> Danilka

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

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

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

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

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

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

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

> 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-средства в серьёзных проектах Найти похожие ветки