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

Question

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

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

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

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

Например:

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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