Лучший способ разработки таблиц базы данных с InterBase? - PullRequest
1 голос
/ 12 июня 2009

Я собираюсь начать переделывать базу данных компании надлежащим образом. Наша текущая база данных в беспорядке и практически не имеет документации. Мне было интересно, что люди рекомендуют использовать при разработке базы данных Interbase? Есть какой-то хороший дизайнер визуальных схем, который будет генерировать SQL? Что лучше сделать все вручную?

В основном, какие шаги обычно предпринимают люди при разработке и документировании базы данных? Если это имеет значение, я намерен использовать Hibernate в качестве ORM для базы данных. (Особые советы с Interbase также приветствуются).

спасибо!

Ответы [ 2 ]

2 голосов
/ 12 июня 2009

Обычно я использую текстовый редактор. Иногда я использую Database Workbench . Последнее, что я слышал, Embarcadero собирался добавить поддержку InterBase к некоторым из своих инструментов моделирования баз данных, но я пока не знаю, была ли она выпущена.

1 голос
/ 12 июня 2009

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

Если я прав по поводу базы данных, которой несколько лет, я настоятельно рекомендую начинать с нуля. Практически любая производственная база данных, которая была около нескольких лет, будет «грязной». Обычно это происходит потому, что реальные требования к программам обычно требуют, чтобы решения были несколько грязными. Это будет справедливо и для вашей новой базы данных (если вы пойдете по этому пути) через несколько лет.

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

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

Вот подход, который я рекомендую:

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

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

...