Один из активных сейчас вопросов навеял опять старую мысль

← →
12 © (2010-09-16 13:55) [0]

Неужели кому-то реально помогло проектировать программы уровня выше "решения квадратного уравнения" во всяческих UML и проч. утилитах?

← →
Думкин © (2010-09-17 05:35) [1]

Вопрос странный. А как еще приемлемо писать и сопровождать программы уровня намного выше

> "решения квадратного уравнения"

И UML - это не утилита.

← →
12 © (2010-09-17 08:47) [2]

т.е. тебе помогло?
И что конкретно?
(кроме структуры БД нарисовать и на бумажке ручкой схемы - это я и сам использую)

> И UML - это не утилита.

Знаю. Специально.

← →
Ega23 © (2010-09-17 08:51) [3]

> Неужели кому-то реально помогло проектировать программы
> уровня выше "решения квадратного уравнения" во всяческих
> UML и проч. утилитах?

Когда в конторе не 5-10, а 150-200 разработчиков, а структура БД over_9000 таблиц, то тогда UML незаменим.
Когда вся база прекрасно сидит у тебя в башке, разработчиков пятеро и все сидят в одной комнате, то оно только пустая трата времени.

← →
12 © (2010-09-17 09:20) [4]

> структура БД over_9000 таблиц

это что же за бедлам такой может быть? :)

← →
oxffff © (2010-09-17 09:23) [5]

> 12 © (17.09.10 09:20) [4]
>
> > структура БД over_9000 таблиц
>
> это что же за бедлам такой может быть? :)

SAP

← →
Alkid © (2010-09-17 09:54) [6]

> 12 © (16.09.10 13:55)
> Неужели кому-то реально помогло проектировать программы
> уровня выше "решения квадратного уравнения" во всяческих
> UML и проч. утилитах?

Ответ положительный.

← →
Ega23 © (2010-09-17 10:41) [7]

> это что же за бедлам такой может быть? :)

Ну, во-первых, Over_9000 - это такой мем на Лурке.
А вообще 500 и более таблиц - ничего необычного.

← →
ЧВ (2010-09-17 12:32) [8]

Ega23 © (17.09.10 10:41) [7]

Тож про лурк недавно узнал ;)?

← →
Ega23 © (2010-09-17 12:33) [9]

> Тож про лурк недавно узнал ;)?

Кто?

← →
ITA (2010-09-17 14:07) [10]

Ega23 © (17.09.10 12:33) [9]

Меня конечно сейчас забанят, но я хочу сказать, что используют сленг в своей речи обычно новоприобщившиеся адепты, среди же прочих нередки дискуссии на тему того, что в речи стоит использовать максимально стилистически-корректную литературную речь, а лурк воообще считается моветоном (к сожалению, за русскими вики-подобными ресурсами закрепилась дурная слава из-за того, что выкладываемый там контент, как правило, является однопроходным продуктом, как, например, результат работы компилятора Дельфи).
Пост же [8] целиком и полностью является своеобразным детектором, на который вы не стали бы отвечать, если бы находились в контексте.

----

По поводу же сабжа - пишите проектную документацию, господа. Для любого сколько-нибудь серьезного проекта, хоть какую-нибудь, но пишите. Да и комментарии тоже неплохо было бы писать.
Заведите вики или базу знаний. Заставили работать компонент, пропатчив модуль A? Напишите как вы это сделали, в противном случае будете вспоминать этот совет хорошими словами, когда придется делать это снова. Придумали хорошую изящную иерархию классов? Сделайте UML диаграмму, самую простую, и поддерживайте ее более-менее актуальной, ибо через пару лет придется вам чертыхаясь снова разбираться в исходном коде. А если и диаграммы эвентов и workflow напишите, то вообще проблем ни каких не будет.

← →
Ega23 © (2010-09-17 14:51) [11]

> а лурк воообще считается моветоном

Любезный, Вы, безусловно, можете посещать исключительно сайты русской словесности. Где даже извиняются, когда пердят.

← →
Anatoly Podgoretsky © (2010-09-17 15:01) [12]

Ой извините.

← →
Юрий Зотов © (2010-09-17 16:01) [13]

Документировать, конечно, надо. Но почему обязательно UML?

← →
TUser © (2010-09-17 16:08) [14]

UML или нет, но в башке держать архитектуру для более 5 тысяч строк - это реально замедляет разработку, имхо. Порог, наверное, индивидуален.

← →
ITA (2010-09-17 16:09) [15]

Юрий Зотов © (17.09.10 16:01) [13]

Велосипеды любите? Люди старались, придумывали универсальную нотацию, которая в идеале должна быть понятна каждому разработчику, а вы: "почему обязательно UML"? Ведь UML это не только er-диаграммы.
А описывать логику можно вообще голым текстом.

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

Ega23 © (17.09.10 14:51) [11]

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

← →
Юрий Зотов © (2010-09-17 16:29) [17]

> ITA (17.09.10 16:09) [15]

1. Велосипеды ни при чем.

2. Люди придумали не только UML. И они тоже старались.

3. За универсальность всегда приходится чем-то платить. Как правило, слжностью, избыточностью, громоздкостью и т.п.

4. Универсальность нужна далеко не всегда. Забивать гвозди можно и отбойным молотком, но обычным - проще, дешевле, быстрее и удобнее.

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

← →
Ega23 © (2010-09-17 16:31) [18]

> Люди старались, придумывали универсальную нотацию, которая
> в идеале должна быть понятна каждому разработчику, а вы:
> "почему обязательно UML"? Ведь UML это не только er-диаграммы.

Везде, где начинается "универсализм", рано или поздно начинается бардак.
Документировать надо ровно так, как тебе удобно. Если тебе обычного txt-файла достаточно - нафига плодить монстроидальные Entity-Relation, Data Flow, Use-Case и прочее?

Был опыт, когда для один проект решили вот так вот построить. Ну и, в результате, на описание каждой фигни времени тратилось в 2 раза больше. А смысл, если над проектом 3 человека работают, и в любой момент один у другого может поинтересоваться: "Вась, а чё это вот тут у тебя?".
Бывает, что и тупо комментариев в коде полностью достаточно.
Бывает и другое, когда каждая строка в коде закомментирована. Видел и такое.
for i := 0 to List.Count - 1 do // Цикл по всем элементам списка List begin // Начало тела цикла end; // Конец тела цикла

← →
Ega23 © (2010-09-17 16:31) [19]

> Юрий Зотов © (17.09.10 16:29) [17]

+1

← →
ocean (2010-09-17 16:36) [20]

Были времена, когда некоторые люди не были знакомы с Интернетом. Некоторые вещи некоторым людям неприятны, например мне неприятны наряды Валерия Леонтьева. Если эти вещи неприятны всем, их можно и нужно забанить, например мат. Если человеку неприятно все, он должен что-то менять.
Я с интересом посмотрел, что за лурк. Спасибо > Ega23 , пора переходить на VGA!

← →
Ega23 © (2010-09-17 16:46) [21]

> пора переходить на VGA

Если ты считаешь, что сострил, то ты глубоко заблуждаешься.
Во-первых, прозвище ЕГА я получил за год до выхода EGA (не говоря уже о массовой известности EGA среди советских школьников).
Во-вторых, за 8 лет такая светлая мысль сострить подобным образом пришла в голову не тебе одному.

← →
Игорь Шевченко © (2010-09-17 16:49) [22]

> Документировать надо ровно так, как тебе удобно

Это архиневерная точка зрения

← →
ocean (2010-09-17 16:58) [23]

> > Документировать надо ровно так, как тебе удобно
>Это архиневерная точка зрения
Документировать надо так, как тебе неудобно

> прозвище ЕГА я получил за год до выхода EGA
А за что?

← →
Ega23 © (2010-09-17 16:58) [24]

> Это архиневерная точка зрения

Почему? Не, ну не то чтобы лично тебе. Тебе - если ты один разработчик. Если команда - есть правила, установленные в команде. И если для команды вполне достаточно комента, о чём юнит в заголовке (или в SVN) и кратких коментов по алгоритму кода - значит так и надо.

← →
Ega23 © (2010-09-17 17:00) [25]

> А за что?

Ты, типа, исповедник, а я, типа, на исповеди?

Впрочем, это не секрет, зовут меня Егоров Олег Вячеславович, и живу я в Падмасковье, где все акают.

← →
Игорь Шевченко © (2010-09-17 17:07) [26]

Ega23 © (17.09.10 16:58) [24]

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

UML - это попытка стандартизировать представление для всех. Любой стандарт обеспечивает как раз то самое понимание и ширину круга.

Я UML не использую и не знаю, но не горжусь этим, а считаю недостатком.

← →
ocean (2010-09-17 17:08) [27]

Видимо, апофигей смысла UML момументально воплощен в камне и бетоне в SAP. Действительно, своей глобальностью эти системы производят впечатление. Но они колоссально неудобны, что приводит к зарплатам специалистов по 7-10 тыс. $. Мне кажется, если подойти к проектированию более творчески, тема открыта.

← →
Юрий Зотов © (2010-09-17 17:11) [28]

Работая в одиночку, документировать действительно можно так, как тебе удобнее.

Работая в конторе, документировать надо так, как принято в этой конторе. Если есть предложения по улучшению или упрощению документирования - изложи их. Докажи, что они полезны и т.п. Но до тех пор, пока твои предложения не приняты и не внедрены - будь добр документировать так, как принято в конторе.

← →
Ega23 © (2010-09-17 17:14) [29]

> Я UML не использую и не знаю, но не горжусь этим, а считаю недостатком.

Знаешь, вот у меня шеф бывший как-то решил перевести то, что мы с Alkid-ом делали на "Новые технологии". И начал всё это описывать в Case-терминах, тем более, что к сертификации готовились. Всякие там DFD, ERD, с привязкой к ревизиям в StarTeam.
Вобщем, трахался-трахался он месяца 3, потом плюнул слюной и на этом всё закончилось. Невыгодно оказалось.

← →
ocean (2010-09-17 17:16) [30]

> Любой стандарт обеспечивает как раз то самое понимание и
> ширину круга.
"Не все стриги, что растет". Стандарт хорош для ремесла и плох в творчестве.
> Работая в конторе, всегда будут лидеры, люди феноменально одаренные и т.д. У кого рука поднимется требовать с них как со всех. Проклятый человеческий фактор. Этим мы сильнее и слабее запада.

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

Ega23 © (17.09.10 17:14) [29]

Ты меня извини, но это сродни, как сосед "Карузо напел - ничего особенного"

← →
Игорь Шевченко © (2010-09-17 17:19) [32]

ocean (17.09.10 17:16) [30]

> Стандарт хорош для ремесла

вообще-то программирование это и есть ремесло

> Этим мы сильнее и слабее запада.

Во-первых, на западе тоже есть человеческий фактор
Во-вторых, посмотри, где сделаны программы, установленные на твоем компьютере, а потом говори про "сильнее запада". То, что слабее - безусловно

← →
Ega23 © (2010-09-17 17:24) [33]

> Ты меня извини, но это сродни, как сосед "Карузо напел -
> ничего особенного"

Почему? Сами тоже пытались. Но гораздо дольше уходит взять, запустить какой-нибудь RationalRouse, там схемки посавить, комментарии расписать, все свойства определить.
Или пойти в курилку с блокнотом, там начиркать модель, вырывая друг у друга ручку.

Мне это сразу напоминает товарища Фарфуркиса напоминает

Фарфуркис глядел на меня с радостным изумлением. Видно было, что он считает мою идею гениальной и сейчас лихорадочно обдумывает возможные пути захвата командных высот в этом новом, неслыханном мероприятии. Уже виделось ему, как он составляет обширную, детальнейшую инструкцию, уже носились перед его мысленным взором бесчисленные главы, параграфы и приложения, уже в воображении своем он консультировал Говоруна, организовывал курсы русского языка для особо одаренных клопов, назначался главой Государственного комитета пропаганды вегетарианства среди кровососущих, расширяющаяся деятельность которого охватит также комаров и мошку, мокреца, слепней, оводов и муху-зубатку…

← →
ocean (2010-09-17 17:26) [34]

> Игорь Шевченко © (17.09.10 17:19) [32]
Согласен в обоих случаях, хотя и с сожалением. Я имел в виду, что мы сильнее духом... Что тут еще скажешь... Но я не верю, что Виндоус делали "через" UML.

← →
Ega23 © (2010-09-17 17:27) [35]

> Но я не верю, что Виндоус делали "через" UML.

Вот как раз там он крайне необходим.

← →
ocean (2010-09-17 17:36) [36]

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

← →
Ega23 © (2010-09-17 17:45) [37]

> Там необходимо тщательнейшее проектирование, но никто не
> требует, чтобы оно было автоматическим.

Камрад, ты вообще знаешь, что такое UML и как им пользоваться?

← →
Игорь Шевченко © (2010-09-17 17:52) [38]

Ega23 © (17.09.10 17:24) [33]

Пойди в курилку, когда ты здесь, а коллега в Новосибирске. Все подметки стопчешь, пока до курилки дойдешь.

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

← →
Ega23 © (2010-09-17 17:55) [39]

> Пойди в курилку, когда ты здесь, а коллега в Новосибирске.
> Все подметки стопчешь, пока до курилки дойдешь.

Игорь, ты обратил внимание, что я в [3] написал:

> Когда в конторе не 5-10, а 150-200 разработчиков, а структура
> БД over_9000 таблиц, то тогда UML незаменим.
> Когда вся база прекрасно сидит у тебя в башке, разработчиков
> пятеро и все сидят в одной комнате, то оно только пустая
> трата времени.

← →
ocean (2010-09-17 17:56) [40]

> ты вообще знаешь, что такое UML и как им пользоваться?
Это такой микрофон, чтобы петь как Карузо.

← →
Ega23 © (2010-09-17 18:00) [41]

> Это такой микрофон, чтобы петь как Карузо.

Я почему-то от тебя другого и не ожидал вовсе.

← →
ocean (2010-09-17 18:07) [42]

Это язык моделирования, и им не пользуются, а пользуются одной из модных систем, где он реализован. Причем поскольку у нас его притягивают за уши, я имею в виду прежде всего свою контору, дальше картинок и диаграмм дело не идет. А задуман он совсем для другого. Кстати, ты с ходу развернулся от своего начального тезиса. Значит ли это, что четкого мнения про UML у тебя нет?

← →
Ega23 © (2010-09-17 18:11) [43]

> Это язык моделирования, и им не пользуются, а пользуются
> одной из модных систем, где он реализован.

И как это у меня получается на UML-диаграммки карандашиком на бумажке рисовать, а?

> Кстати, ты с ходу развернулся от своего начального тезиса.

Я свой начальный тезис сформировал ещё в [3], если тебе так будет угодно. И мой тезис отнюдь не означает, что я не умею пользоваться различными Case-системами или не знаю UML. Просто я его не использую повсеместно на работе, где надо и где не надо.

> Значит ли это, что четкого мнения про UML у тебя нет?

Да, это так.

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

Ega23 © (17.09.10 17:55) [39]

а ты обратил внимание, что я писал в [26] ?

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

Чем более широкоиспользуемый стандарт при этом применяется, тем лучше. Заметь, я не говорю, что все, кто не использует, должны сдохуть в адском пламени, переведены в дворники, и т.п. Я говорю - стоит стремиться :)

← →
Ega23 © (2010-09-17 18:16) [45]

> Я говорю - стоит стремиться :)

Не уверен. "Краткие описания сущности необъяснимого явления" тоже ничего.

← →
Anatoly Podgoretsky © (2010-09-17 18:38) [46]

> Ega23 (17.09.2010 17:00:25) [25]

Привет Егоров Алег

← →
Anatoly Podgoretsky © (2010-09-17 18:42) [47]

> Но они колоссально неудобны, что приводит к зарплатам специалистов
> по 7-10 тыс. $.

И ты говоришь неудобен :-)
Да им удалось достигнуть большего чем с СИ

← →
AlexDn © (2010-09-17 19:20) [48]

> Anatoly Podgoretsky © (17.09.10 18:42) [47]
>
> > Но они колоссально неудобны, что приводит к зарплатам
> специалистов
> > по 7-10 тыс. $.
>
> И ты говоришь неудобен :-)
> Да им удалось достигнуть большего чем с СИ
кстати о си, поставил себе Microsoft Visual Studio 2010 Professional плачу..

← →
Anatoly Podgoretsky © (2010-09-17 19:28) [49]

> AlexDn (17.09.2010 19:20:48) [48]

От счастья, или с горя, или на высокую зарплату расчитываешь?

← →
AlexDn © (2010-09-17 19:31) [50]

> Anatoly Podgoretsky © (17.09.10 19:28) [49]
такое впечатление что он на две головы выше любого делфи-компиллятора
но конечно время создания любого проекта в 2-3 раза увеличивается..

← →
картман © (2010-09-17 19:35) [51]

> такое впечатление что он на две головы выше любого делфи-
> компиллятора
> но конечно время создания любого проекта в 2-3 раза увеличивается.
> .

это вот как? "Моя машина самая быстрая, но ездит в два раза медленнее"

← →
Anatoly Podgoretsky © (2010-09-17 19:50) [52]

> AlexDn (17.09.2010 19:31:50) [50]

> в 2-3 раза увеличивается..

Значит еще более долгоиграющий проект. Вот так надо защищать рабочие места.

← →
AlexDn © (2010-09-17 19:53) [53]

> картман © (17.09.10 19:35) [51]
Универсальность поражает прежде всего, c++, с#, asp.net, базы данных, visual basic, F# и всё в одном флаконе как говориться..

← →
Sha © (2010-09-17 20:01) [54]

> AlexDn © (17.09.10 19:53) [53]

Это важно. Писать на всем сразу.

← →
картман © (2010-09-17 20:30) [55]

> AlexDn © (17.09.10 19:53) [53]

так вроде бы версии 2005 и 2008 этих парсеров различных синтаксисов, тоже все это поддерживали?

← →
Ega23 © (2010-09-17 21:00) [56]

> Универсальность поражает прежде всего, c++, с#, asp.net,
> базы данных, visual basic, F# и всё в одном флаконе как
> говориться..

И чо, батя вон статьи свои в TurboEdit писал (это редактор для TurboPascal под DOS) в формате LaTex (TexScript или как-то так). И программы. И ini-файлы. И до сих пор пишет.
Вся жизнь в TurboEdit.
А ты говоришь студия 10-я...

← →
Ega23 © (2010-09-17 21:01) [57]

> Привет Егоров Алег

Это ещё ничего, некоторые считали, что меня Алек зовут.

← →
Alkid © (2010-09-17 21:21) [58]

По поводу документации есть еще один аспект проблемы - что надо, а что не надо документировать. Тяжеловесные процессы типа RUP тяготеют к полной документации всего, но это очень дорого - доки надо писать и потом поддерживать в актуальном состоянии. С другой стороны, всякий agile стремится иметь как можно меньше документации, но это накладывает повышенные требования на квалификацию программистов и уровень коммуникаций в команде.

← →
Alkid © (2010-09-17 21:23) [59]

А касаемо UML: это очень богатый стандарт и досконально его знаю, наверное, очень мало людей. Но при использовании некоторого подмножества он становится реально удобным способом передачи знания.

← →
Игорь Шевченко © (2010-09-17 23:37) [60]

Alkid © (17.09.10 21:21) [58]

> С другой стороны, всякий agile стремится иметь как можно
> меньше документации, но это накладывает повышенные требования
> на квалификацию программистов и уровень коммуникаций в команде

насколько я понимаю, "всякий agile" он как раз для узкого круга тесно общающихся разработчиков. 5-10 человек где-то. Если я не прав, прошу поправить :)

← →
Marser © (2010-09-17 23:38) [61]

Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете (с)

Это относится и к документированию.

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

← →
иксик © (2010-09-18 00:14) [62]

> Пишите код так, как будто сопровождать его будет склонный
> к насилию психопат, который знает, где вы живете (с)

Гениально!

← →
Anatoly Podgoretsky © (2010-09-18 06:10) [63]

> Ega23 (17.09.2010 21:01:57) [57]

Они с Падонки.ру не знакомы,

← →
Anatoly Podgoretsky © (2010-09-18 06:12) [64]

> Alkid (17.09.2010 21:23:59) [59]

Какая тогда польза от него, если его почти никто не занет.

← →
Alkid © (2010-09-18 09:58) [65]

> Игорь Шевченко © (17.09.10 23:37) [60]
> насколько я понимаю, "всякий agile" он как раз для узкого
> круга тесно общающихся разработчиков. 5-10 человек где-то.
> Если я не прав, прошу поправить :)

Да, именно так. Это я к тому, что политика документирования должна подстраиваться под процесс.
Лично я считаю, что надо стремиться к тому, что бы документации был минимум при сохранении разумного порога вхождения для новичков. Для этого должно быть очень высокое качество кода и архитектуры.

← →
Alkid © (2010-09-18 09:59) [66]

> Anatoly Podgoretsky © (18.09.10 06:12) [64]
> > Alkid (17.09.2010 21:23:59) [59]
>
> Какая тогда польза от него, если его почти никто не занет.

Его почти никто не знает досконально. Но базовые знания достаточно распространены (по моему опыту).

← →
Ega23 © (2010-09-18 11:27) [67]

> Да, именно так. Это я к тому, что политика документирования
> должна подстраиваться под процесс.

Лёха, вспомни, как Андрей 3 месяца use-case и dfd всякие к АРМу пытался разрисовать. И чем дело кончилось.
Внатуре, от фотографирования доски пользы было бы гораздо больше. :))))

← →
Alkid © (2010-09-18 16:29) [68]

> Ega23 © (18.09.10 11:27) [67]

Это, кстати, плохо, что оно так кончилось :) Если бы эту работу умело сделали, то мы бы лучше в итоге справились. А у нас не хватило понимания методики разработки. Знание uml, dfd и других страшных слов не помогло :)

← →
Фокс Йовович (2010-09-19 19:21) [69]

на UML гораздо проще общаться с коллегами по рабочим вопросам

← →
Kerk © (2010-09-19 20:15) [70]

> Marser © (17.09.10 23:38) [61]
>
> Вообще, причина сабжа в том, что нишей Делфи остались небольшие
> локальные проекты. Программист на C# скорее всего никогда
> не задаст подобного вопроса, ведь он зачастую и сам спел
> обжечься там, где не было документации, а структуру проекта
> можно было добыть только из светлых голов его косноязыких
> коллег.

Бред же. Ничем в данном контексте программист на Delphi от остальных не отличается. Скорее даже наоборот. На C# стартует куда больше новых проектов и соответственно куда больше программистов не почувствовали на себе все прелести поддержки старого кода.

← →
Kerk © (2010-09-19 20:25) [71]

> иксик © (18.09.10 00:14) [62]
>
> > Пишите код так, как будто сопровождать его будет склонный
> > к насилию психопат, который знает, где вы живете (с)
>
> Гениально!

Цитатами из Макконнела можно стены обклеивать. В принципе, даже просто целиком страницами :)

← →
Думкин © (2010-09-22 05:44) [72]

> 12 © (17.09.10 08:47) [2]
>
> т.е. тебе помогло?
> И что конкретно?
> (кроме структуры БД нарисовать и на бумажке ручкой схемы
> - это я и сам использую)

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

> это что же за бедлам такой может быть? :)

Ну, вот у нас таблиц не одна тысяча. Сколько - надо поднимать данные. И как-то рулим. Это помимо Аксапты причем, замечу. В ней еще несколько. Вот и набирается. И как раз это и дает порядок, а не 10 универсальных табличек для всех случаев жизни с миллионом пятьсот столбцов и сотней состояний.

← →
12 © (2010-09-22 09:36) [73]

> > это что же за бедлам такой может быть? :)
> SAP

+

> А вообще 500 и более таблиц - ничего необычного.

+

> Думкин © (22.09.10 05:44) [72]

а Том Кайт писал, что если в программе более (не помню точно сколько, но явно меньше 50) таблиц - то БД спроектирована не оптимально с вероятностью более 90%

← →
Думкин © (2010-09-22 09:43) [74]

> 12 © (22.09.10 09:36) [73]

А кто это такой? Это бабушка твоя Том Кайт, дедушка твой? :) Видимо, он тоже не понимает зачем больше 50 таблиц в программе не сложнее решения квадратного уравнения. :)

Ну, или мы таки попадаем в 10%.

← →
Kerk © (2010-09-22 10:14) [75]

> Думкин © (22.09.10 09:43) [74]
>
> > 12 © (22.09.10 09:36) [73]
>
> А кто это такой? Это бабушка твоя Том Кайт, дедушка твой? :)

Том Кайт - это гуру Oracle.

← →
Kerk © (2010-09-22 10:15) [76]

Томас (Том) Кайт — вице-президент корпорации Oracle, возглавляющий группу Oracle Public Sector, известен также как эксперт в области разработки приложений для СУБД Oracle. Ведущий популярного одноименного сайта AskTom («Cпроси у Тома»), посвященного проблемам и методам их решений в СУБД Oracle, а также постоянный автор журнала Oracle Magazine. Томас Кайт — автор нескольких бестселлеров по СУБД Oracle.

← →
Ega23 © (2010-09-22 10:23) [77]

Ну Тому Кайту, конечно, виднее, куда до Тома Кайта всяким Стоунбрейкерам...

← →
Думкин © (2010-09-22 10:23) [78]

> Kerk © (22.09.10 10:14) [75]

Да я знаю уж.

← →
12 © (2010-09-22 11:05) [79]

опять же
универсальность vs заточенность на задачу

почему то заточенность более симпатична. Громоздкая система часто не оправдана.
ну и ИШ как то сказал (цитировал кого-то)- не стремись к универсальности

Ща отсебятину сказану:
Есть БД. Есть процессы(не те, которые рождаются по CreateProcess :) ).
Пусть каждый процесс юзает свои таблицы и часть таблиц других процессов, где ему надо по бизнес-логике.
И тут 50 таблиц на процесс вполне нормально, даже много.
Так вот: Не стоит вводить суперпроцесс контроля всех таблиц, коотрых реально может оказаться более 50. (Кайт - не бог, с вероятностью 100% :) )

спасибо за внимание.

← →
Думкин © (2010-09-22 11:11) [80]

> 12 © (22.09.10 11:05) [79]

Кто на ком стоял, я не понял. Но берем обычную систему которая должна обслуживать Заказы и Закупки, со всей логистикой и платежами и уже получаем не так уж мало таблиц. Причем без фанатизма даже.

← →
Ega23 © (2010-09-22 11:13) [81]

> Кто на ком стоял, я не понял. Но берем обычную систему которая
> должна обслуживать Заказы и Закупки, со всей логистикой
> и платежами и уже получаем не так уж мало таблиц. Причем
> без фанатизма даже.

Угу.

← →
Юрий Зотов © (2010-09-22 12:14) [82]

Что сказал Том Кайт точно?

Точно он сказал вот что: если в БД более N таблиц, то с вероятностью более 90% она спроектирована неоптимально.

Это означает, что лишь 10% разработчиков способны оптимально спроектировать БД с количеством таблиц более N. С чем вполне можно согласиться.

Но Том Кайт не говорил, что не должно быть БД с количеством таблиц более N. И не надо ему этого приписывать.

← →
12 © (2010-09-22 12:24) [83]

> если в БД более N таблиц, то с вероятностью более 90% она
> спроектирована неоптимально.

да, как-то так

> Но Том Кайт не говорил, что не должно быть БД с количеством таблиц более N. И не надо ему этого приписывать

да, не говорил
нет, не надо

> Это означает, что лишь 10% разработчиков способны оптимально
> спроектировать БД с количеством таблиц более N.

необязательно означает именно это.

← →
Думкин © (2010-09-22 12:35) [84]

> 12 © (22.09.10 12:24) [83]

Замечание было не в твою сторону.

← →
vuk © (2010-09-22 12:36) [85]

Нда. У нас в базе где-то полтыщи таблиц. Это, видать, от того, что мы совсем лохи, ага.

← →
Юрий Зотов © (2010-09-22 12:37) [86]

> 12 © (22.09.10 12:24) [83]

Практически, именно это и означает. БД с 50-ю и более таблицами встречаются сплошь и рядом - и не потому, что они плохо спроектированы, а потому, что такова предметная область.

И уж кто-кто, а Том Кайт, безусловно, прекрасно это знает. Как знает и то, что разработчиков, способных спроектировать такую БД оптимально, совсем немного. О чем и сказал.

← →
Юрий Зотов © (2010-09-22 12:45) [87]

Берем, например, систему документооборота. Документы - разных видов, с разным набором полей. Для хранения документов одного вида заводится таблица с соответствующим набором полей. Пусть имеем 50 видов документов (что совсем немного) - сразу получаем 50 таблиц. Это не считая справочников и служебных таблиц, которых тоже может быть немало.

Замените "вид документа" на "вид товара" - получите то же самое. И т.п.

И что, Том Кайт не знает таких вещей? Трудно поверить.

← →
vuk © (2010-09-22 12:49) [88]

to Юрий Зотов © (22.09.10 12:45) [87]:

> Замените "вид документа" на "вид товара" - получите то же
> самое. И т.п.

Не, не получим. Таки товар - это сущность более простая.

← →
Ega23 © (2010-09-22 12:56) [89]

> Не, не получим. Таки товар - это сущность более простая.

Я бы не стал столь категорично утверждать, от предметной области зависит. Но в целом - согласен.

← →
Юрий Зотов © (2010-09-22 12:57) [90]

> vuk © (22.09.10 12:49) [88]

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

← →
12 © (2010-09-22 13:05) [91]

Убедили.
Насчет 50 - Кайт видимо предостерегал начинающих, в более метафорной форме

пол-тыщи таблиц..
и сколько записей в них?
У нас тоже есть одна - пол года там 2 записи лежат неизменными, и пол-года строчишь join всякий раз
Неужели нет таких, которые можно объединить в ущерб нормализации?

← →
Ega23 © (2010-09-22 13:06) [92]

> А если брать, то у холодильника они одни, а у стиральной
> машины - другие.

create table Goods ( GoodID int PK GoodName varchar(...), ..... ) create table GoodParams ( UID int PK, GoodID int FK на Goods, ParamValue ... ..... )

Всё от специфики зависит.

← →
Alkid © (2010-09-22 13:08) [93]

> Kerk © (19.09.10 20:15) [70]
> > Marser © (17.09.10 23:38) [61]

А кто такие эти "программисты на Дельфи" и "программисты на С#"? И какова корреляция между тем инструментом, который они сейчас используют и опытом поддержки?

← →
vuk © (2010-09-22 13:11) [94]

to Юрий Зотов © (22.09.10 12:57) [90]

> Это если не брать специфические характеристики товара (изделия).
> А если брать, то у холодильника они одни, а у стиральной
> машины - другие.

Вот ты верно заметил - специфические характеристики. Вот их и хранить отдельно. Причем, не очень долго думая, приходим к формату хранения, грубо говоря, "параметр-значение". После чего становится глубоко пофиг, параметры чего хранить.

← →
vuk © (2010-09-22 13:28) [95]

to 12 © (22.09.10 13:05) [91]:

> пол-тыщи таблиц..
> и сколько записей в них?

А где как. Где-то совсем мало, а где-то миллионы.

> Неужели нет таких, которые можно объединить в ущерб нормализации?

Я не вижу смысла смешивать сущности только ради того, чтобы устранить некоторое количество таблиц. Ведь количество таблиц - не самоцель и не главный критерий.

← →
Думкин © (2010-09-22 13:47) [96]

> 12 © (22.09.10 13:05) [91]

Есть с одной записью. И нормализации во многих нет.

← →
Alkid © (2010-09-22 15:34) [97]

> vuk © (22.09.10 13:11) [94]
> Вот ты верно заметил - специфические характеристики. Вот
> их и хранить отдельно. Причем, не очень долго думая, приходим
> к формату хранения, грубо говоря, "параметр-значение". После
> чего становится глубоко пофиг, параметры чего хранить.

Тогда возникает резонный вопрос - а зачем в таком случае использовать РСУБД?

← →
12 © (2010-09-22 15:38) [98]

> Alkid © (22.09.10 15:34) [97]

а какие есть не Р, нормальные? (скорость, документация, проверка временем, имя солидной компании за спиной, что б было понятно - завтра проект не бросят)
И главное - а что уже на таких сделано?

← →
b z (2010-09-22 15:44) [99]

to Alkid © (22.09.10 15:34) [97]:

> Тогда возникает резонный вопрос - а зачем в таком случае
> использовать РСУБД?

Это надо понимать, как предложение часть реализовывать на реляционной модели, а часть - нет? И, кстати, каким боком реляционная модель здесь мешает? Вполне нормальная схема "сущность - характеристика - значение".

> b z (22.09.10 15:44) [99]
> > 12 © (22.09.10 15:38) [98]
> Лотус, не?

да я не знаю, я спрашиваю
наверное не так написал, как наезд - это не так :)

> а какие есть не Р, нормальные? (скорость, документация,
> проверка временем, имя солидной компании за спиной, что
> б было понятно - завтра проект не бросят)

Caché, Postgres.

> И главное - а что уже на таких сделано?

Рамблер, например.

> 12 © (22.09.10 15:38) [98]
> а какие есть не Р, нормальные? (скорость, документация,
> проверка временем, имя солидной компании за спиной, что
> б было понятно - завтра проект не бросят)
> И главное - а что уже на таких сделано?

Ну вот, что-то нагуглил: http://en.wikipedia.org/wiki/Nosql

> vuk © (22.09.10 15:49) [100]
> Это надо понимать, как предложение часть реализовывать на
> реляционной модели, а часть - нет? И, кстати, каким боком
> реляционная модель здесь мешает? Вполне нормальная схема
> "сущность - характеристика - значение".

Нет, просто РСУБД, поддерживающая множество таблиц и ссылочную целостность становится тут overkill`ом.

to Alkid © (22.09.10 16:03) [104]:

> Нет, просто РСУБД, поддерживающая множество таблиц и ссылочную
> целостность становится тут overkill`ом.

С какого перепугу-то?

> а Том Кайт писал, что если в программе более (не помню точно
> сколько, но явно меньше 50) таблиц - то БД спроектирована
> не оптимально с вероятностью более 90%

Ты не того Кайта читал

> Ты не того Кайта читал

завтра напишу книгу, главу, абзац
т.к. книга дома

vuk © (22.09.10 13:11) [94]

> Причем, не очень долго думая, приходим к формату хранения,
> грубо говоря, "параметр-значение". После чего становится
> глубоко пофиг, параметры чего хранить

Цитата (из Тома Кайта):

"Довольно часто встречаются приложения, построенные с использованием универсальных моделей данных для максимальной гибкости, и приложения, построенные так, что они мешают работе. Например, хорошо известно, что можно представить любой объект в базе данных используя только четыре таблицы:

create table objects (oid int pimary key, name varchar2(255));
create table attributes (attrid int primary key, attrname varchar2(255),
datatype varchar2(25));
create table object_attributes (oid int, attrid int, value varchar2(4000),
primary key (oid,attrid));
create table links (oid1 int, oid2 int, primary key (oid1, oid2));

Но как такая модель работает ? Простой запрос select first_name, last_name from person трансформируется в соединение трех таблиц с аггрегированием, более того, если имеются атрибуты NULLABLE - в таком случае может не быть строки в таблице object_attributes для некоторых атрибутов, - возможно, возникнет необходимость использовать внешнее соединение, которое может исключить оптимальные планы запросов из рассмотрения.

Мой совет всем: будьте более специализированы м менее универсальными. Несомненно, общий подход более гибкий, но менее производительный, более сложный, с точки зрения формирования запросов и сопровождения. Не используется словарь данных и метаданные. Те, кто применяет универсальный подход, загоняют себя в угол."

(с) Том Кайт "Эффективное проектирование приложений Oracle"

> vuk © (22.09.10 16:10) [105]
> С какого перепугу-то?

С такого, что вся БД вырождается в отображение <entity, attribute> -> <value>. Если я правильно читал википедию, то это как раз идея Google Big Table, одной из нереляционных субд.

to Игорь Шевченко © (22.09.10 16:38) [108]:
Это все понятно. Но я вовсе не призывал все хранить в виде атрибутов объектов. Речь шла о конкретном применении - товары и их характеристики. Причем, как раз с учетом реляционной модели с её ссылочной целостностью, хранение информации о товарах делать в виде таблиц разной структуры под разные типы товаров как раз глупо и бессмысленно.

to Alkid © (22.09.10 16:51) [109]:

> С такого, что вся БД

Я где-то предлагал всю БД так реализовывать?

to Alkid © (22.09.10 18:01) [111]:
У нас уже лет десять так живут технические характеристики товаров:

http://www.fcenter.ru/products.shtml?eshop/act=h:a:0:7:a:a:a:0:a:1:30:r:1:1:&oper=85313::::

В данный момент это реализовано именно как хранение наборов (код_товара-имя_параметра-значение). Сейчас, правда, будем внутреннюю реализацию переделывать на более строгие связи. Если упрощенно, то будет так: (код_товара-код_характеристики-значение). Впрочем, пользователи разницы не заметят, но некоторые сервисы будет реализовать проще.

> завтра напишу книгу, главу, абзац

не, не напишу :)

все перепутал -
Это не он был, а Пол Нильсен
Не про oracle, а про mssql

в книге
http://oz.by/books/more.phtml?id=1039662&partner=booky
и сказал он как-то так

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

и приводится пример, когда он переделал БД из ~80 таблиц в БД с 17 таблицами.

А Кайт - про "неуниверсальность" писал, да, Игорь привел уже.

> и приводится пример, когда он переделал БД из ~80 таблиц
> в БД с 17 таблицами.

Можно, вообще, все в одну таблицу упихать. А смысл?

> А смысл?

разумное упрощение
там же он пишет
- все надо делать как можно проще, но не проще этого.
Чем все проще сделано - тем легче поддерживать и развивать.

там же пишет, что любит браться за проекты, обреченные с т.з. заказчика.
Типа, вытащите проект - заплачу. Нет - я уже его похоронил.
и в большинстве случаев помогает упрощение

> Не про oracle, а про mssql

И не выиграл, а проиграл (с)

> разумное упрощение

Разумную денормализацию ещё никто не отменял. Но именно разумную. Когда в жертву скорости осознанно приносится гибкость и расширяемость.

to 12 © (23.09.10 09:25) [113]:

> Если разработчик хвалится что создал БД с великим множеством
> таблиц, я чаще всего считаю что он создал провальную БД.
>

А если БД, несмотря на данное заявление, получается не провальной, то видимо провальным можно считать данное заявление. Я правильно понял? :)

> А если БД, несмотря на данное заявление, получается не провальной,
> то видимо провальным можно считать данное заявление. Я
> правильно понял? :)

не :)

> я чаще всего считаю что он создал провальную БД.

и вообще написал, т.к. грозился привести "книгу, абзац " и т.п.
а что облажался малость - ну надо и об этом сказать :)

Ну вот, например, по инсайдерской информации, в некоторых известных highload интернет проектах в базе даже ключи не используют. Потому что считают, что к базе все через клиента ходят, а клиент написан правильно.

> Ega23 © (23.09.10 11:46) [121]

Нас недавно в конторе посылали на курсы, где про всякие Enterptise Pattern`ы говорили, и ведущий упоминал о таком подходе, когда говорил про реализации ORM.

> Потому что считают, что к базе все через клиента ходят,
> а клиент написан правильно.

FoxPro: Revival

> и ведущий упоминал о таком подходе, когда говорил про реализации
> ORM.

ORM -- это, натурально, секта, навроде сайентологии.

Самое забавное - это смотреть на ORMщиков, не знающих SQL :)

> DiamondShark © (23.09.10 13:11) [123]
> ORM -- это, натурально, секта, навроде сайентологии.

Не только ORM :)
Имхо, самая деструктивная секта - это ООП.

Но и то и то приносит пользу, если без фанатизма и по делу применять.

> Но и то и то приносит пользу, если без фанатизма и по делу
> применять.

всякий овощ приносит пользу будучи употреблен надлежащим образом в надлежащее время :)

> Игорь Шевченко © (23.09.10 14:07) [126]
> всякий овощ приносит пользу будучи употреблен надлежащим
> образом в надлежащее время :)

Простая истина, но к ней приходишь только после набивания шишек об Универсальные Серебряные Овощи - Решатели Всех Проблем Раз И Навсегда :)

> Простая истина, но к ней приходишь только после набивания
> шишек об Универсальные Серебряные Овощи - Решатели Всех
> Проблем Раз И Навсегда :)

"Система приобретает вид лома с кучей настраиваемых шарниров" (с)

> Ega23 © (23.09.10 14:19) [128]
>
> "Система приобретает вид лома с кучей настраиваемых шарниров"
> (с)

Во-во, именно так.
И так сладко звучали слова "абсолютно все можно будет настроить" :))))

to Ega23 © (23.09.10 14:19) [128]:

> "Система приобретает вид лома с кучей настраиваемых шарниров"
> (с)

Гибкость, плавно переходящая в кривизну.

> И так сладко звучали слова "абсолютно все можно будет настроить" :))))

Иэхххх, время было-то!!!!

В PTC Windchill код во многом генерируется из моделей, хотя во многих частях от этого подхода отказываются. Хорошо это или плохо - спорный вопрос. Типичный размер установленного продукта 1-2G (это именно продукт без базы данных).

http://www.ptc.com/products/windchill/

> Игорь Шевченко (23.09.2010 14:07:06) [126]

Правильно грибы надо курить, а не жарить.

> Kerk © (19.09.10 20:15) [70]
>
>
> Бред же. Ничем в данном контексте программист на Delphi
> от остальных не отличается. Скорее даже наоборот. На C#
> стартует куда больше новых проектов и соответственно куда
> больше программистов не почувствовали на себе все прелести
> поддержки старого кода.

Не отличается? Ну, пока не попадаешь в матёрый аутсорс, может и не отличается. А на Шарпе таких проектов гораздо больше, чем на Делфи, даже прямо скажем - их там большинство.
Вопрос не в том, что в Делфи моэно теоретически сделать то-то и то-то, вопрос в том, что происходит в объективной реальности.
Кстати, если проект стартовал, то там намутить можно за полгода...

> Marser © (23.09.10 20:52) [136]

А чегго же пишет Керк? Он и пишет:

> На C# стартует куда больше новых проектов

в чем проблема?

Новизна у него = отсутствие чужого кода.

> Marser © (23.09.10 20:52) [136]
> Не отличается? Ну, пока не попадаешь в матёрый аутсорс,
> может и не отличается.

Чет тебя второй день уже капец как заносит.
Смотри мессией не стань.

> Новизна у него = отсутствие чужого кода.

Посмотри в гугле определение слова "новизна".

Особенно интересно прикинуть какой процент этих студентов-сишарперов сталкивался с 10-15летним унаследованным кодом.

> Посмотри в гугле определение слова "новизна".

Ты сказал, что стартуют новые проекты, подразумевая отсутствие старого кода.
Но как бы это... Шарпу уже десять лет...
Хотя да, на Делфи приходилось иметь дело с кодом 1996 года, тоже, кстати, израильским. И, кстати, возвращаясь к тебе сабжа, он был документирован в общих чертах, что немало упрощало работу.

Один из активных сейчас вопросов навеял опять старую мысль Найти похожие ветки