wadmanMikhail Tchervonenkoкстати обнуляю я их не в программе а в скрипте который генерирует таблицы.
Почему этот-же скрипт не (пере)создает генераторы для создаваемых таблиц?
тут согласно внутренней политике все изменения в базе ведутся через скрипты. Если в базе создаётся блок по смыслу связанных таблиц то до первого релиза программы работающей с этим блоком удобно иметь скрипт который создаёт таблицы (если они не созданы ещё), копирует в них какие то данные и изменяет структуру таблиц в хронологическом порядке. При этом желательно если в процессе тестирования какие то данные добавились в таблицы не удалять их без особой нужды (это к вопросу почему просто не пересоздать генераторы). После выхода первого релиза, под каждый новый релиз, создаётся свой скрипт который вносит уже только изменения в структуру таблиц и если необходимо добавляет новые. Это очень удобно если разработку надо вести и вне пределов фирмы, напр, дома на ноуте. Зачекал скрипт из svn, накатил и получил последний вариант структуры базы. Безусловно иногда и дамп базы накатить приходится но это времязатратно и не всегда необходимо.

А индексы привык использовать либо из комбинации полей, и только если нужна порядковая нумерация автоинкремент. В некоторых случаях удобны GUID подобные индексы, особенно если нужно уникальность поля не только в рамках таблицы но и в рамбках базы или многих баз. К такому GUID удобно привязывать все (логгирование, блокировки итп вещи если они реализовываются не родными средствами сервера баз данных). Автоинкремент плох, с моей точки зрения, дополнительными проблеммами при синхронизации или слиянии данных. Думаю эти проблеммы и без меня всем хорошо известны. Вот собственно и все.

Симонов ДенисMikhail Tchervonenko,

IBExpert прекрасно умеет генерировать скрипт обновления при сравнении как с контрольной БД, так и со скриптом. Так что напрасно вы себя так мучаете.

Тут это отчасти с документированием связано итп Да и не я правила устанавливаю (пока).
Достоинство скрипта в том что он может и с нуля все сделать и интеллектуально по задуманной логике, на мой испорченный взгляд удобно. Конечно не так как это в Visual Studio реализовано (см. проект базы), но хоть что то. Если бы у FireBird было что то что позволяет напрямую хранить структуру базы и скрипты в SVN как это реализовано в продуктах для MSSQL то было бы намного удобнее.

Вообще надо идею подкинуть разработчикам IBExpert сделать интеграцию с svn и git. Было бы удобно.

PEAKTOPMikhail TchervonenkoАвтоинкремент плох, с моей точки зрения, дополнительными проблеммами при синхронизации или слиянии данных.

у ERP-шников есть правило: первичный ключ (ID-записи) не должен нести НИКАКОЙ информации об объекте в базе.
еще раз: НИКАКОЙ! это просто идентификатор записи.

если нужно уникальное значение, одинаковое для всех баз (например, штрих-код товара), то заводится дополнительный домен в таблице.

а проблемы синхронизации решаются путем дополнительной таблицы, в которой есть домены:

Да, примерно так на MsSQL и делали всегда. Единственное в качестве первичного ключа всегда пользовал GUID что позволяло обойтись без вышеописанной таблицы.

kdvMikhail Tchervonenko Если бы у FireBird было что то что позволяет напрямую хранить структуру базы и скрипты в SVN
isql -x и закидывай в SVN.
Такое тоже используем.
Но только что б потом сравнить что изменили.