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

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

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

  • DatabaseProject
    • Functions
      • (all functions here; no further nesting)
    • StoredProcedures
      • (all stored procs in here; no further nesting)
    • Views
      • (ditto)

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

Например:

  • DatabaseProject
    • Reports
      • (individual stored procs, views, etc.)
      • SpecificReport
        • (more objects here, further nesting as necessary)
    • SpecificApplication
      • (all types of DB objects, with arbitrarily deep nesting)
    • и так далее ....

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

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


database version-control code-organization project-organization
person Zach Blocker    schedule 18.06.2009    source источник

Ответы (3)


arrow_upward
1
arrow_downward

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

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

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

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

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

person Mac    schedule 04.08.2009
comment
Я бы меньше беспокоился о беспорядке из-за множества небольших файлов SQL, если бы я мог расположить их во вложенных папках по темам приложений, чтобы они не мешали. В нашем предыдущем решении, где у нас было всего несколько папок: StoredProcedures, Views, Functions, Triggers и т. Д., У нас действительно были очень большие беспорядочные папки. - person Zach Blocker; 05.08.2009

arrow_upward
1
arrow_downward

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

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

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

person devio    schedule 18.06.2009
comment
Я должен был упомянуть: мы приняли простую венгерскую нотацию для объектов нашей базы данных. К именам объектов добавляются символы sp для хранимой процедуры, vw для представления и fn для функции. Что обычно происходит в нашей плоской структуре хранения, так это то, что для того, чтобы объекты базы данных были организованы по субъектам, мы стремимся создавать префиксы все большего размера, такие как spEAWizardDoSomething. В этом имени есть три префикса: sp для хранимой процедуры, EA как код для конкретного приложения и Wizard для обозначения дополнительной части приложения EA, в данном случае мастера. - person Zach Blocker; 19.06.2009
comment
Кроме того, вся причина, по которой я предлагаю это, заключается в том, что для меня недостаточно разделить объекты по базовому типу (представление, функция и т. Д.). Я ненавижу открывать папку StoredProcedures и видеть в ней сотни файлов из разных кусочки нашего решения. - person Zach Blocker; 19.06.2009
comment
что может использовать имя объекта db для получения его полного имени пути, например sp \ EA \ Wizard \ spEAWizardDoSomething.sql. В конце концов, это зависит только от схемы, которую вы составляете. - person devio; 19.06.2009
comment
Я определенно вижу в этом возможности. Минусы тоже. Например, вместо EA я бы предпочел назвать папку ElectronicAbacus (или как-то иначе), но оставил бы EA в имени объекта. Кроме того, я бы не хотел, чтобы папка верхнего уровня была sp, потому что, опять же, я не хочу отделять хранимые процедуры от представлений и функций в этой системе; Я хочу, чтобы все соответствующие объекты БД были в одной папке; вы можете использовать венгерскую нотацию, чтобы отличить хранимую процедуру от представления. - person Zach Blocker; 19.06.2009

arrow_upward
0
arrow_downward

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

person Chris McCall    schedule 04.08.2009