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

Question

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

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

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

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

Например:

• DatabaseProject
  • Reports
    • (отдельные сохраненные процедуры, представления и т.д.)
    • SpecificReport
      • (больше объектов здесь, дальнейшее вложение по мере необходимости)
  • SpecificApplication
    • (все типы объектов БД, с произвольно глубокой вложенностью)
  • et cetera....

Очевидным недостатком является то, что эта структура папок не налагает никакой иерархии пространства имен на объекты базы данных;это только для организации.Таким образом, это было бы очень легко вводить объекты с повторяющимися именами.Вам понадобится какой-нибудь инструмент сборки, чтобы изучить проект базы данных и устранить конфликты именования.

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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