История изменений

1. Имей систему сборки, которая гарантированно приводит серверную часть к тому, что у тебя в sql скриптах (файлах).

2. Храни sql скрипты в системе контроля версий. Объяви sql скрипты официальным местом хранения исходников серверной части, а всё, что занесено в базу напрямую DDL запросами - это фигня, пока его нет в скриптах.

3. Сделай систему патчей, которая управляет модификацией метаданных. В патчи заноси все DDL запросы, модифицирующие структуру таблиц, а также все DML запросы, которые производятся при апгрейде базы. Модифицируй все свои базы только через систему патчей. Для хранимых процедур и триггеров это обычно не нужно - ты хранишь не дельту состояния, а последнее состояние (пп 1-2). Хотя бывают всякие случаи.

4. Имей инструмент, выдающий дампы двух баз и сравнивающий эти дампы почленно. В простейшем случае - выдать дамп каждого объекта по алфавиту и потом гуишный diff.

5. Поддерживай тестовую базу с неизменными данными. Имея пп 1,2,3 - не трудно будет модифицировать её структуру по ходу развития промышленной базы. На самом деле у тебя будет не менее 3 баз, если ты работаешь один: разработческая, тестовая и боевая. Если ты работаешь не один, то баз может быть значительно больше. И все их можно поддерживать с помощью п.п.1,2,3.

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

6. Тестируй на этой самой выделенной тестовой базе. Если ты сделаешь её из промышленной, у тебя сразу же будет возможность тестировать и производительность, что не менее важно, чем тестирование правильности запросов.

У меня руки так и не дошли до создания системы автотестов, потому что последняя разработанная мной система недостаточно долго прожила в промышленной эксплуатации. Ну и плюс лень и нерадение. Но если бы я стал делать автотесты для БД, то сделал бы именно так.

пп 1-4 я реализовал (для MSSQL и для Firebird).

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

А уж лисповые клиенты СУБД обычно возвращают данные в виде деревьев.

1. Имей систему сборки, которая гарантированно приводит серверную часть к тому, что у тебя в sql скриптах (файлах).

2. Храни sql скрипты в системе контроля версий. Объяви sql скрипты официальным местом хранения исходников серверной части, а всё, что занесено в базу напрямую DDL запросами - это фигня, пока его нет в скриптах.

3. Сделай систему патчей, которая управляет модификацией метаданных. В патчи заноси все DDL запросы, модифицирующие структуру таблиц, а также все DML запросы, которые производятся при апгрейде базы. Модифицируй все свои базы только через систему патчей. Для хранимых процедур и триггеров это обычно не нужно - ты хранишь не дельту состояния, а последнее состояние (пп 1-2). Хотя бывают всякие случаи.

4. Имей инструмент, выдающий дампы двух баз и сравнивающий эти дампы почленно. В простейшем случае - выдать дамп каждого объекта по алфавиту и потом гуишный diff.

5. Поддерживай тестовую базу с неизменными данными. Имея пп 1,2,3 - не трудно будет модифицировать её структуру по ходу развития промышленной базы. На самом деле у тебя будет не менее 3 баз, если ты работаешь один: разработческая, тестовая и боевая. Если ты работаешь не один, то баз может быть значительно больше. И все их можно поддерживать с помощью п.п.1,2,3.

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

6. Тестируй на этой самой выделенной тестовой базе. Если ты сделаешь её из промышленной, у тебя сразу же будет возможность тестировать и производительность, что не менее важно, чем тестирование правильности запросов.

У меня руки так и не дошли до создания системы автотестов, потому что разработанная мной система недостаточно долго прожила в промышленной эксплуатации. Ну и плюс лень и нерадение. Но если бы я стал делать автотесты для БД, то сделал бы именно так.

пп 1-4 я реализовал (для Firebird).

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

А уж лисповые клиенты СУБД обычно возвращают данные в виде деревьев.

1. Имей систему сборки, которая гарантированно приводит серверную часть к тому, что у тебя в sql скриптах (файлах).

2. Храни sql скрипты в системе контроля версий. Объяви sql скрипты официальным местом хранения исходников серверной части, а всё, что занесено в базу напрямую DDL запросами - это фигня, пока его нет в скриптах.

3. Сделай систему патчей, которая управляет модификацией метаданных. В патчи заноси все DDL запросы, модифицирующие структуру таблиц, а также все DML запросы, которые производятся при апгрейде базы. Модифицируй все свои базы только через систему патчей. Для хранимых процедур и триггеров это обычно не нужно - ты хранишь не дельту состояния, а последнее состояние (пп 1-2). Хотя бывают всякие случаи.

4. Имей инструмент, выдающий дампы двух баз и сравнивающий эти дампы почленно. В простейшем случае - выдать дамп каждого объекта по алфавиту и потом гуишный diff.

5. Поддерживай тестовую базу с неизменными данными. Имея пп 1,2,3 - не трудно будет модифицировать её структуру по ходу развития промышленной базы. На самом деле у тебя будет не менее 3 баз, если ты работаешь один: разработческая, тестовая и боевая. Если ты работаешь не один, то баз может быть значительно больше. И все их можно поддерживать с помощью п.п.1,2,3.

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

6. Тестируй на этой самой выделенной тестовой базе. Если ты сделаешь её из промышленной, у тебя сразу же будет возможность тестировать и производительность, что не менее важно, чем тестирование правильности запросов.

У меня руки так и не дошли до создания такой системы, потому что разработанная мной система не долго прожила в промышленной эксплуатации. Ну и плюс лень и нерадение. Но если бы я стал делать автотесты для БД, то сделал бы именно так.

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

А уж лисповые клиенты СУБД обычно возвращают данные в виде деревьев.

1. Имей систему сборки, которая гарантированно приводит серверную часть к тому, что у тебя в sql скриптах (файлах).

2. Храни sql скрипты в системе контроля версий. Объяви sql скрипты официальным местом хранения исходников серверной части, а всё, что занесено в базу напрямую DDL запросами - это фигня, пока его нет в скриптах.

3. Сделай систему патчей, которая управляет модификацией метаданных.

4. Имей инструмент, выдающий дампы двух баз и сравнивающий эти дампы почленно. В простейшем случае - выдать дамп каждого объекта по алфавиту и потом гуишный diff.

5. Поддерживай тестовую базу с неизменными данными. Имея пп 1,2,3 - не трудно будет модифицировать её структуру по ходу развития промышленной базы. На самом деле у тебя будет не менее 3 баз, если ты работаешь один: разработческая, тестовая и боевая. Если ты работаешь не один, то баз может быть значительно больше. И все их можно поддерживать с помощью п.п.1,2,3.

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

6. Тестируй на этой самой выделенной тестовой базе. Если ты сделаешь её из промышленной, у тебя сразу же будет возможность тестировать и производительность, что не менее важно, чем тестирование правильности запросов.

У меня руки так и не дошли до создания такой системы, потому что разработанная мной система не долго прожила в промышленной эксплуатации. Ну и плюс лень и нерадение. Но если бы я стал делать автотесты для БД, то сделал бы именно так.

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

А уж лисповые клиенты СУБД обычно возвращают данные в виде деревьев.

1. Имей систему сборки, которая гарантированно приводит серверную часть к тому, что у тебя в sql скриптах (файлах).

2. Храни sql скрипты в системе контроля версий.

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

4. Тестируй на ней.

Я сам так не делал по лени и нерадению, но если бы я стал делать, то сделал бы именно так.

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

А уж лисповые клиенты СУБД обычно возвращают данные в виде деревьев.

1. Имей систему сборки, которая гарантированно приводит серверную часть к тому, что у тебя в sql скриптах.

2. Храни sql скрипты в системе контроля версий.

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

4. Тестируй на ней.

Я сам так не делал по лени и нерадению, но если бы я стал делать, то сделал бы именно так.

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

А уж лисповые клиенты СУБД обычно возвращают данные в виде деревьев.