Стоит ли головная боль организовывать SQL файлы по тематике приложения?

В моей компании мы сохраняем каждый объект базы данных (хранимый proc, view и т. д.) как отдельный файл SQL и помещаем их под управление версиями таким образом.

До сих пор у нас была очень плоская модель хранения в нашей версионной файловой структуре:
  • DatabaseProject
    • Functions
      • (все функции здесь; без дальнейшей вложенности)
    • StoredProcedures
      • (все хранимые процедуры в дальнейшие гнездование)
    • Views
      • (то же самое)

Для большого нового проекта мне пришла в голову другая идея: почему бы не хранить эти файлы по темам, а не в этих сборных плоских списках?

Например:

  • DatabaseProject
    • Reports
      • (отдельные хранимые процессы, представления и т. д.)
      • SpecificReport
        • (здесь больше объектов, далее вложенность как необходимо)
    • SpecificApplication
      • (все типы объектов БД, со сколь угодно глубокой вложенностью)
    • и так далее....
Очевидный недостаток заключается в том, что эта структура папок не накладывает никакой иерархии пространств имен на объекты базы данных; она предназначена только для организации. Таким образом, было бы очень легко ввести объекты с повторяющимися именами . Вам понадобится какой-то инструмент сборки, чтобы исследовать проект базы данных и умирают от конфликтов имен.

Что я хотел бы знать: кто-нибудь пробовал этот метод организации файлов SQL по предмету приложения в их версионной файловой структуре? Стоило ли оно того? Вы создали инструмент сборки, который будет контролировать проект, как я описал?

3 2
database version-control project-organization

3 ответа:

Мне нравится, чтобы мои SQL-скрипты были организованы по темам, а не по имени. Как правило, я даже группирую связанные элементы в отдельные файлы. Основными преимуществами этого являются:

  • Вы не загромождаете свою файловую систему / IDE файлами (многие из них имеют длину в несколько строк).
  • общая структура базы данных показывает более непосредственно.
С другой стороны, найти исходный код, относящийся к конкретному объекту, может оказаться сложнее...

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

В заключение я бы сказал, что ваши нынешние правила намного лучше, чем отсутствие правил вообще.
1

Вы должны определить схему именования для объектов базы данных, чтобы было понятно, где используется представление или SP.

Это могут быть либо префиксы для описания модулей приложения, либо отдельные имена схем для модулей/функций.

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

1

Мы сохраняем наши файлы SQL в папке решения" SQL " с каждым проектом. Таким образом, каждый проект "устанавливается" отдельно.

0