Форум: "Прочее";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];
ВнизПосоветуйте СУБД Найти похожие ветки
← →
Павел Калугин © (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-Дамп из модели, накатываешь на БД - и опля, счастье?
← →
AV © (2012-09-19 11:30) [69]Имхо, Инструмент удобен, если его сразу применять.
Т.е. создали сразу в нем, любое изменение - в нем.
Если схема в др.филиале должна отличатся - надо строить общую схему.
Наши объекты + их объекты.
И сверху общие объекты, как переходники/интерфейсы
Для наглядности момента можно распечатывать не всю схему, а только часть. Легко выбирается что скрыть, что нет
Если уже имеющееся подгонять - это трудно :). Попытки видел, результат нет.
← →
AV © (2012-09-19 11:40) [70]
> По мере неё полюбому что-то меняется, добавляются таблицы,
> правятся текущие и так далее. При этом появляется полюбому
> тестовые всякие штуки.
Если они прижились - они попадают в модель, надо только не запускать
Если они не попали в модель, горе тому кто их юзает
← →
Ega23 © (2012-09-19 11:44) [71]
> Ты нарисовал модель в PD, все прописал - супер. Экспортнул
> модель в базу, зашибись.
> Я не знаю других вариантов, как дальше писать средствами
> далеко не PD, а всяких специализированных тулз - всяческие
> серверные API. В общем, БД-разработка начинается. По мере
> неё полюбому что-то меняется, добавляются таблицы, правятся
> текущие и так далее. При этом появляется полюбому тестовые
> всякие штуки.
1. Тестовые штуки - это на тестовом сервере, там на усмотрение того, кто этим тестом занимается. Хучь в блокноте скрипты пишет - его личное дело.
2. В PD при генерации скрипта можно отметить, что именно тебе нужно выгружать. Создал объект - ну и генери скрипт на создание только его, в чём проблема?
3. В PD можно сравнить модель с физической БД и сгенерить скрипт на изменение данных (причём скрипт очень неплохой делается, надо отдеть должное).
4. В PD можно полный скрипт всей модели сгенерить, для разворачивания с нуля.
Как-то так.
З.Ы. PD - не панацея, что-то руками иногда допиливать нужно, что-то наоборот дополнительно делать. Но помогает зверски. Это как тот же IDE в Delphi - можешь вообще не пользоваться, а всё в блокноте писать и потом из cmd компилятор вызывать. Ненаказуемо. Но - странно, должны быть веские основания.
В целом - лучшего "общего" инструмента для проектировки БД я пока не встречал. Есть ещё всякие Maestro, Паша Голубь тоже что-то такое делал (уже забыл, как называется). Но они - узкозаточенные под конкретную СУБД. PD же довольно легко расширяем и довольно гибко настраивается.
З.З.Ы. Надо действительно 16-ю версию посмотреть, есть подозрение, что они здорово продвинулись.
← →
Пит (2012-09-19 11:44) [72]
> Если они прижились - они попадают в модель
ага, Гарри Поттер палочкой махает - и оно попадает в модель.
← →
AV © (2012-09-19 11:49) [73]
> ага, Гарри Поттер палочкой махает - и оно попадает в модель.
Зачем, ведущий разраб БД получает указание, применить фичу такую то. Если он сам ее придумал, он пишет доку. Если кто-то, то дока с него.
Если руководство Г Поттера наймет на должность ведущего БД- то он будет :)
← →
MsGuns © (2012-09-19 11:51) [74]>И в результате, Ega23, у тебя через 2 года была реально синхронизированная модель базы в PD? Ты мог ИЗ ПОД PD над чистым инстансом развернуть всю структуру БД и иерархию БД, необходимую для работы? То есть, генеришь полный SQL-Дамп из модели, накатываешь на БД - и опля, счастье?
Вполне реально. Если есть небольшой проект, требующий постоянной поддержки (например 1С-подобный для масштаба уровня "склада"). И проектирование, и развитие, и инсталляция и суппорт - вполне по силам одному человеку. А если еще учесть что клиентура может быть огого, то PD вполне может облегчить жизнь девелопера :)
← →
Ega23 © (2012-09-19 12:24) [75]Я просто не по наслышке знаю ситуацию, когда именно несколько (ну порядка десятка) человек могли модифицировать БД. В результате получился уродливый монстр, состоящий из ~ 2000 таблиц, в которых дублируются данные, которые переплетены в такой граф, что сам Эйлер задолбается в нём циклы искать, а Гамильтон - пути. В котором 100500 пакетов, состоящих из 100500 функций, которые повторяют функционал друг-друга. Ну и т.д.
И один хрен кончилось всё нанятием серьёзного специалиста, который всё это дело разгрёб (за год, примерно). И теперь НИКТО кроме него не может изменять структуру БД на боевом сервере. На тестовых - это ради бога, на то он и тестовый.
А вот в чём ведёт базу этот человек - это опять же его личное предпочтение. Но я бы выбрал именно PD.
← →
Павел Калугин © (2012-09-19 12:36) [76]
> Ega23 © (18.09.12 16:20) [47]
> Да, ну и, собственно, самое главное: бумажку с фломастером
> в SVN не засунешь. В отличие от pdm-файла.
Да у ПД и свой репозиторий не плох. Или зачем в SVN коме как для контроля версий совать
← →
Jeer © (2012-09-19 12:37) [77]Для Oracle - вполне достойный Oracle Data Modeler, который еще с MS SQL и DB работает.
← →
Ega23 © (2012-09-19 12:38) [78]
> Или зачем в SVN коме как для контроля версий совать
Для контроля версий и совать, одного pdb недостаточно (это backup который)
← →
Kerk © (2012-09-19 13:29) [79]Только Toad Data Modeler! Только хардкор! :)
← →
MsGuns © (2012-09-19 14:14) [80]Жаба - это круто !!!!!
Страницы: 1 2 3 4 вся ветка
Форум: "Прочее";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];
Память: 0.64 MB
Время: 0.066 c