Посоветуйте СУБД

← →
Павел Калугин © (2012-09-18 14:48) [40]

Удалено модератором

← →
Ega23 © (2012-09-18 15:19) [41]

Удалено модератором

← →
Ega23 © (2012-09-18 15:22) [42]

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

← →
Пит (2012-09-18 15:37) [43]

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

во-о-о. А я о чем?

Вопрос терминологии. Как можно некое средство X называть мощнейшим и незаменимым, если обыкновенная бумага и ручка делают где-то также?
Ты это понимаешь, я это понимаю - это прекрасно.
Если мы понимаем плюсы и минусы того и другого - это еще лучше.

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

← →
Пит (2012-09-18 15:45) [44]

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

два раза ха-ха.

Ega23, скажи честно - ты реальную БД, ну хотя бы таблиц на сотню, синхронизированную с PD - видал? Я попытки - видел, о результатах - вот спешу доложить. У-ТО-ПИ-Я.

Еще раз. При больших БД - это нереально в силу огромных трудозатрат, ора девелоперу гораздо проще поправить в БД, чем править в PD, а потом накатывать на базу. Или каждый раз потом реверсить!! Я такое видел, такое только в гос. конторах могут придумать и реализовать, будет работать пока вливают миллионы денег.

При малых БД это тупо теряет смысл, ибо технология то как раз для больших БД ) Маленькую БД-схемку на ватмане можно распечатать - замечательно смотрится и всё понятно ) А pd нифига не дешевый еще при этом.

Частичное наполнение БД - тоже геморойное в силу поддержки БД окружения.
Я например видел решения, когда ради этого отказывались от foreign ключей в БД, чтобы можно было БД править из PowerDesigner, иначе осотонеешь. Лично готов был вручить медаль данным товарищам.

В общем, разубеди меня. И приведи, пожалуйста, реальный пример большого, качественного проекта, когда схему оры (ну или там другой БД) наполял реально Power Designer

← →
Ega23 © (2012-09-18 16:00) [45]

> Ega23, скажи честно - ты реальную БД, ну хотя бы таблиц
> на сотню, синхронизированную с PD - видал?

Я тебе отвечу честно: я БД с ~ 200 таблиц именно в нём с нуля создал и именно в нём её и сопровождал. Где-то года 2.5.

> Я например видел решения, когда ради этого отказывались
> от foreign ключей в БД, чтобы можно было БД править из PowerDesigner,
> иначе осотонеешь. Лично готов был вручить медаль данным
> товарищам.

Там есть весьма неплохой скриптовый язык. Его - достаточно.

> когда схему оры (ну или там другой БД) наполял реально
> Power Designer

PD не для этого предназначен. Да, какие-то сугубо справочные и не редактируемые таблицы в AferCreation-скрипте наполнить можно.
Остальное - не имеет смысл.

← →
Пит (2012-09-18 16:18) [46]

> Да, какие-то сугубо справочные и не редактируемые таблицы
> в AferCreation-скрипте наполнить можно.

под наполнением схемы я не данные имел в виду. Я имел в виду именно DDL.

> Я тебе отвечу честно: я БД с ~ 200 таблиц именно в нём с
> нуля создал и именно в нём её и сопровождал. Где-то года
> 2.5.

опа-на.

- И еще можно, если честно? Ты готов повторить этот опыт и дальше так сопровождать БД, причем учти, что обычно БД разрабатывают несколько людей, а то и десятки?

- Можешь описать как у тебя происходили изменения?

В чем основная заковыка. Ты как разработчик делаешь таблицу, прикинул, написал метод в package - ага, понадобилось новая колонка - допилил, связал. Что-то убрал, временную таблицу для тестов снес, оценил скорость, если нужно - пошел дальше... Проводить все это КАЖДЫЙ раз через PD - зопа.
Делать ПОСЛЕ серии изменений реверс в PD? есть очень много тонкостей. Очень интересно - ты как работал то?

- Что ты делал с наполнением базы? Ок, забудем про данные как таковые, но как же например тексты хранимок, package"ей, триггеров и прочее?

← →
Ega23 © (2012-09-18 16:20) [47]

Да, ну и, собственно, самое главное: бумажку с фломастером в SVN не засунешь. В отличие от pdm-файла.

← →
Ega23 © (2012-09-18 16:26) [48]

> Ты готов повторить этот опыт и дальше так сопровождать БД

Безусловно.

> причем учти, что обычно БД разрабатывают несколько людей,
> а то и десятки?

Это, извините, бардак в консерватории. Разрабатывать её может сколько угодно людей. А вот вносить правки - только один.

> но как же например тексты хранимок, package"ей, триггеров
> и прочее?

Гм... Я с трудом себе представляю отладку хп в PD. Для этого Management Studio есть.

← →
Медвежонок Пятачок © (2012-09-18 17:29) [49]

а с учетом еще и того, что одинаковых схем могут быть десятки на разных серверах в разных городах, то обновление их через sql+ и *.cmd в пакетном режиме - добро.
а всякие PD - смерть.или геморройнее в стопитсот раз.

← →
Ega23 © (2012-09-18 17:33) [50]

> то обновление их через sql+ и *.cmd в пакетном режиме - добро.

Дык так и делалось. Но вот генерация патч-скрипта - как раз PD

← →
Медвежонок Пятачок © (2012-09-18 17:46) [51]

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

← →
Ega23 © (2012-09-18 18:03) [52]

> зачем?

Я не настаиваю. Если кому-то проще на бумажке с фломастером схему БД рисовать и в нотепаде скрипты писать - Б-гъ в помощь.

← →
Пит (2012-09-18 18:29) [53]

> Разрабатывать её может сколько угодно людей. А вот вносить
> правки - только один.

ха. Тебе не кажется ты на начальном этапе философии к БД?
Чем БД от исходников дельфи отличается? Ты сейчас сказал:

"Разрабатывать исходный код может сколько угодно людей. А вот вносить
правки в проект - только один.".

Слушай, ну фигня же. Проблема только в том, что в текущих БД нету аля svn"а. Так ты его можешь и сам реализовать. Запрет на модификацию, триггера на DDL, клиентское ПО по чекину, чекауту, add - и вот тебе SVN на девелоперскую БД. А вот переносит на боевой уже да, обычно один. И тот админ, а не разработчик.
И десятки людей делают БД, а как еще в крупном проекте?!?!

← →
Пит (2012-09-18 18:36) [54]

Ega23, ты так и не ответил на основной вопрос...

Если PD это - рисование прямоугольников - пожалуйста. Тоже самое умеет Visio, тоже самое рисуется на бумажке, тоже самое рисуется фломастером на совещаниях на досках.
Подход один, есть плюсы минусы.

ДРУГОЕ - это именно генерация базы из модели, накат изменений из модели, короче полная синхронизация модели и базы. Я видел это... и это ЗОПА.

Первое что я хочу оговорить - мы НЕ идем на то, чтобы отказываться от вкусных фич БД, чтобы УДОБНЕЕ было иметь синхронизированную версию в PD.

Второе - ответь, пожалуйста, как же ты всё таки проводил разработку?! Я не верю, что у тебя не было тестовых таблиц, набросок, оценок скоростей, производительности и так далее. В процессе разработки ты постоянно что-то меняешь, допиливаешь, удаляешь, добавляешь, опять удаляешь, модифицируешь. Делать это каждый раз через PD... Не верю, что ты такой извращанец и более того тебе это понравилось ))

Значит, ты делал реверс... То есть, сначала ты как разработчик с помощью некой студии разрабатывал БД, хранимки, а потом обратно реверсил в PD, да?

Но тогда смысл этого PD. Получается так, изначально мы спроектировали БД в PD, набросали схемки, все хорошо. Сделали скрипт и сделали базу. В результате разработки (да хотя бы те же пэкэджи писать и хранимки) полюбому что-то меняется, корректируется. Значит, обратно реверсить в модель?
Потом править в модели и накатывать на базу?

И ты так делал КАЖДЫЙ РАЗ в течении более двух лет? И так до конца имел ПОЛНУЮ синхронизированную модель ВСЕЙ БД? То есть, ты мог развернуть чистую структуру БД на новом сервере и приложение начало бы работать?

← →
Ega23 © (2012-09-18 19:44) [55]

> ха. Тебе не кажется ты на начальном этапе философии к БД?
> Чем БД от исходников дельфи отличается?
... ну и дальше много текста.

Считаю дальнейший диалог бессмысленным. Твоему крупному проекту желаю всяческих благ, удачи и процветания.
Да, если это потешит твоё ЧСВ, то можешь произнести "Слифф зощитан", мне фиолетово.

← →
Пит (2012-09-18 20:33) [56]

Хм, не понимаю чем ты оскорбился.

Мне действительно интересно узнать, как в PD можно без двойной работы поддерживать актуальность с реальной БД. Я вроде и так спросил, и эдак.
Ну не хочешь делиться секретами - как хочешь )

← →
Ega23 © (2012-09-18 22:01) [57]

> Хм, не понимаю чем ты оскорбился.

Я? Оскорбился? Да полноте...
Просто есть мнение, что в вашей консерватории - бардак-с, только и всего.

← →
Jeer © (2012-09-18 22:15) [58]

> Просто есть мнение, что в вашей консерватории - бардак-с,
> только и всего.
>

Хорошо, когда "один в доме", все остальное рано или поздно подвержено увеличению энтропии, хотя и первое - тоже :)

← →
MsGuns © (2012-09-19 10:31) [59]

Вот мне тупо интересно, как в нормальной оре-базе с сотнями тысяч объектов (нескольких десятков тысяч только таблиц), может "рукоблудить" только лишь один человек ?
И еще интересно, в чем заключается работа девелопера БД, не могущего вносить правки в метаданные - типа Петьки с гранатой, разгоняющего танки в старом анекдоте ?

Для девелоперов-одиночек типа Ежи, тянущих базки уровня склада, конечно, такой инструмент, может, и находка. Однако цена !

← →
знайка (2012-09-19 10:34) [60]

> А Visio то в общем не совсем для этого...
А для чего?

← →
Ega23 © (2012-09-19 10:54) [61]

> нескольких десятков тысяч только таблиц

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

← →
brother © (2012-09-19 10:55) [62]

гугл? впрочем, номенклатура не та...

← →
Kerk © (2012-09-19 10:57) [63]

> Ega23 © (19.09.12 10:54) [61]

Да что там десяток тысяч таблиц. Бывают таблицы с сотнями полей.

← →
Anatoly Podgoretsky © (2012-09-19 11:06) [64]

> Kerk (19.09.2012 10:57:03) [63]

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

← →
знайка (2012-09-19 11:07) [65]

> десяток тысяч таблиц
Сколькож такой девелопер получает? даже если по баксу на таблицу, ого сумма.. :)

← →
Ega23 © (2012-09-19 11:08) [66]

> Да что там десяток тысяч таблиц. Бывают таблицы с сотнями
> полей.

Это да, вот SAP пример животворящий, далеко ходить не надо.
И всё-таки. Десяток тысяч таблиц. Созданных не в динамике, a-la 1С, а осознанно ручками. Без разнесения на отдельную сотню схем, а переплетённых друг-с-другом.
Ганс, приведи пример, тебя же за язык никто не тянул.

← →
MsGuns © (2012-09-19 11:22) [67]

>Ega23 © (19.09.12 10:54) [61]
>Назови мне, пожалуйста, такую контору. У которой есть база с десятком тысяч таблиц.

"Парус". "Укртелеком".
И это далеко не самая крутая контора.
И это далеко не самая крутая ERP

← →
Пит (2012-09-19 11:25) [68]

> Я? Оскорбился? Да полноте...
> Просто есть мнение, что в вашей консерватории - бардак-с,
> только и всего.

возможно!! Но я не понимаю как по-другому! А ты упорно не хочешь рассказать, как это так красиво можно делать через PD!

Ega23, давай еще разок!

Ты нарисовал модель в PD, все прописал - супер. Экспортнул модель в базу, зашибись.
Я не знаю других вариантов, как дальше писать средствами далеко не PD, а всяких специализированных тулз - всяческие серверные API. В общем, БД-разработка начинается. По мере неё полюбому что-то меняется, добавляются таблицы, правятся текущие и так далее. При этом появляется полюбому тестовые всякие штуки.

Что ты с этим делаешь? Постоянный реверс обратно в модель?

И в результате, Ega23, у тебя через 2 года была реально синхронизированная модель базы в PD? Ты мог ИЗ ПОД PD над чистым инстансом развернуть всю структуру БД и иерархию БД, необходимую для работы? То есть, генеришь полный SQL-Дамп из модели, накатываешь на БД - и опля, счастье?

Имхо, Инструмент удобен, если его сразу применять.

Т.е. создали сразу в нем, любое изменение - в нем.
Если схема в др.филиале должна отличатся - надо строить общую схему.
Наши объекты + их объекты.
И сверху общие объекты, как переходники/интерфейсы

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

Если уже имеющееся подгонять - это трудно :). Попытки видел, результат нет.

> По мере неё полюбому что-то меняется, добавляются таблицы,
> правятся текущие и так далее. При этом появляется полюбому
> тестовые всякие штуки.

Если они прижились - они попадают в модель, надо только не запускать
Если они не попали в модель, горе тому кто их юзает

> Ты нарисовал модель в PD, все прописал - супер. Экспортнул
> модель в базу, зашибись.
> Я не знаю других вариантов, как дальше писать средствами
> далеко не PD, а всяких специализированных тулз - всяческие
> серверные API. В общем, БД-разработка начинается. По мере
> неё полюбому что-то меняется, добавляются таблицы, правятся
> текущие и так далее. При этом появляется полюбому тестовые
> всякие штуки.

1. Тестовые штуки - это на тестовом сервере, там на усмотрение того, кто этим тестом занимается. Хучь в блокноте скрипты пишет - его личное дело.
2. В PD при генерации скрипта можно отметить, что именно тебе нужно выгружать. Создал объект - ну и генери скрипт на создание только его, в чём проблема?
3. В PD можно сравнить модель с физической БД и сгенерить скрипт на изменение данных (причём скрипт очень неплохой делается, надо отдеть должное).
4. В PD можно полный скрипт всей модели сгенерить, для разворачивания с нуля.
Как-то так.
З.Ы. PD - не панацея, что-то руками иногда допиливать нужно, что-то наоборот дополнительно делать. Но помогает зверски. Это как тот же IDE в Delphi - можешь вообще не пользоваться, а всё в блокноте писать и потом из cmd компилятор вызывать. Ненаказуемо. Но - странно, должны быть веские основания.
В целом - лучшего "общего" инструмента для проектировки БД я пока не встречал. Есть ещё всякие Maestro, Паша Голубь тоже что-то такое делал (уже забыл, как называется). Но они - узкозаточенные под конкретную СУБД. PD же довольно легко расширяем и довольно гибко настраивается.
З.З.Ы. Надо действительно 16-ю версию посмотреть, есть подозрение, что они здорово продвинулись.

← →
Пит (2012-09-19 11:44) [72]

> Если они прижились - они попадают в модель

ага, Гарри Поттер палочкой махает - и оно попадает в модель.

> ага, Гарри Поттер палочкой махает - и оно попадает в модель.

Зачем, ведущий разраб БД получает указание, применить фичу такую то. Если он сам ее придумал, он пишет доку. Если кто-то, то дока с него.

Если руководство Г Поттера наймет на должность ведущего БД- то он будет :)

>И в результате, Ega23, у тебя через 2 года была реально синхронизированная модель базы в PD? Ты мог ИЗ ПОД PD над чистым инстансом развернуть всю структуру БД и иерархию БД, необходимую для работы? То есть, генеришь полный SQL-Дамп из модели, накатываешь на БД - и опля, счастье?

Вполне реально. Если есть небольшой проект, требующий постоянной поддержки (например 1С-подобный для масштаба уровня "склада"). И проектирование, и развитие, и инсталляция и суппорт - вполне по силам одному человеку. А если еще учесть что клиентура может быть огого, то PD вполне может облегчить жизнь девелопера :)

Я просто не по наслышке знаю ситуацию, когда именно несколько (ну порядка десятка) человек могли модифицировать БД. В результате получился уродливый монстр, состоящий из ~ 2000 таблиц, в которых дублируются данные, которые переплетены в такой граф, что сам Эйлер задолбается в нём циклы искать, а Гамильтон - пути. В котором 100500 пакетов, состоящих из 100500 функций, которые повторяют функционал друг-друга. Ну и т.д.
И один хрен кончилось всё нанятием серьёзного специалиста, который всё это дело разгрёб (за год, примерно). И теперь НИКТО кроме него не может изменять структуру БД на боевом сервере. На тестовых - это ради бога, на то он и тестовый.
А вот в чём ведёт базу этот человек - это опять же его личное предпочтение. Но я бы выбрал именно PD.

> Ega23 © (18.09.12 16:20) [47]
> Да, ну и, собственно, самое главное: бумажку с фломастером
> в SVN не засунешь. В отличие от pdm-файла.

Да у ПД и свой репозиторий не плох. Или зачем в SVN коме как для контроля версий совать

Для Oracle - вполне достойный Oracle Data Modeler, который еще с MS SQL и DB работает.

> Или зачем в SVN коме как для контроля версий совать

Для контроля версий и совать, одного pdb недостаточно (это backup который)

Только Toad Data Modeler! Только хардкор! :)

Жаба - это круто !!!!!

Посоветуйте СУБД Найти похожие ветки