Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2006.10.08;
Скачать: [xml.tar.bz2];

Вниз

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, являющиеся отображениями объектов.



Страницы: 1 2 вся ветка

Форум: "Прочее";
Текущий архив: 2006.10.08;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.56 MB
Время: 0.109 c
15-1158217488
k2
2006-09-14 11:04
2006.10.08
"Методология повышения производительности вещественных и ..."


15-1158082467
Kolan
2006-09-12 21:34
2006.10.08
Принимайте во второй клуб :)


3-1154535572
StriderMan
2006-08-02 20:19
2006.10.08
Имя таблицы как параметр запроса


15-1158667458
dgim
2006-09-19 16:04
2006.10.08
Файлы....


15-1158205348
PSPF2003
2006-09-14 07:42
2006.10.08
Какой Linux?





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский