Как вы создаете и обновляете свои сценарии SQL?

Мне интересно, как лучше всего создавать и поддерживать карты баз данных и сценарии SQL. Я знаю, что мне больше нравится писать сценарий SQL вручную в текстовом редакторе (плюс проектировать карту, которая будет рядом со мной на листе бумаги), в то время как другие предпочитают использовать программное обеспечение для карт баз данных (MySQL Workbench, Visual Studio ... некоторые из них перечислены в этом сообщении) для автоматического создания сценария.

Оба решения имеют свои достоинства и недостатки. Я вижу эти преимущества:

  • SQL script by hand:
    1. You know exactly what you write.
    2. Вы можете сохранить чистый и легко читаемый код SQL.
    3. Написав код, вы лучше понимаете специфику своей базы данных.
    4. Написание кода позволяет вам улучшить свои знания SQL.
  • Automatically generated script from designed map:
    1. Saves some time.
    2. Даже не зная языка SQL, вы можете сгенерировать сценарий (даже если я перечислил его как противоположное преимущество для сценария SQL вручную).
    3. Предотвращает опечатки.

Как вы думаете, по какому пути вы будете двигаться дальше?


sql database database-design sql-scripts diagram
person Otiel    schedule 04.07.2011    source источник

Ответы (1)


arrow_upward
7
arrow_downward

Если автоматизация чего-то экономит время и экономит человеческие ошибки, почему бы вам этого не сделать? Я бы попробовал автоматически сгенерировать SQL, если:

  1. Я уже заполнил тестовую базу данных и построил схему естественным образом, написав и выполнив специальные SQL-запросы, которые я не отслеживал; а также
  2. Если база данных была достаточно простой и с небольшим объемом нормализации

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

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

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

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

INSERT INTO DB_VERSION (upgrade_time, version_from, version_to, comment)
    VALUES ('2011-07-04T120320', '2.2.4', '2.3', 'add column x to table y.')
person Lisa    schedule 04.07.2011
comment
Db_version (которую я также использую) имеет другое, более важное применение. Это необходимо, чтобы гарантировать простой путь обновления для db. Обычно у меня есть сценарии обновления, которые выполняют обновление только с версии X до версии Y, проверяя текущую версию. Если мне нужно выполнить обновление с предыдущих версий, мне нужно выполнить правильную последовательность сценариев обновления. - person Frazz; 26.08.2014