Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 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
1-1297521334
Slava.yo
2011-02-12 17:35
2013.03.22
Автопрокрутка в Webbrowser


15-1344870494
stas
2012-08-13 19:08
2013.03.22
DelphiXE 2 FireMonkey


15-1351492704
oldman
2012-10-29 10:38
2013.03.22
Задачка. Ответа я не знаю.


2-1333447731
Цукор5
2012-04-03 14:08
2013.03.22
Объединение мелких файлов в один большой


2-1347989696
vegarulez
2012-09-18 21:34
2013.03.22
синхронизация потока.





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
Английский Французский Немецкий Итальянский Португальский Русский Испанский