Я неоднократно делал это с обеих сторон (потребитель и поставщик) как администратор баз данных, разработчик и архитектор.
Как поставщик, одним из моих великих достижений (в 1996 году) было создание установочного компакт-диска для программного продукта управления страховыми претензиями, предназначенного для крупнейших страховых компаний (предмет стоимостью в несколько миллионов долларов). На этом установочном компакт-диске были установлены ядро СУБД Oracle 7.2, оптическая система хранения FileNet (сканирует бумажные документы и создает каталогизированные двоичные версии) и наше специальное приложение для обработки заявок (встроенное в VB 4.0), все они интегрированы и готовы к работе. В рамках процесса установки пользователь может пропустить установку программного обеспечения Oracle или настроить его, а пользователь может настроить / переопределить конфигурацию базы данных во всех ее основных деталях (база данных, схемы, табличные пространства, размеры, диски и т. Д.).
Я также предоставил полевой сервис для этого продукта, который при необходимости включал в себя посещение сайта клиента. Я тестировал установочный компакт-диск буквально сотни раз при каждом мыслимом сценарии, который я мог воспроизвести, и у нас НИКОГДА не было полевого отказа, который требовал даже телефонного звонка, не говоря уже о поездке (я путешествовал четыре раза, но для предпродажных вещей вместо этого).
Совсем недавно (2007) я написал сценарий создания базы данных Oracle 10g для внутренней системы в мегакорпусе. На производстве размер базы данных составлял 8 ТБ, в основном для одной таблицы транзакций с большим объемом данных. В тесте база данных была размером около 1 ТБ для скромного сервера. В процессе разработки размер базы данных составлял около 100 МБ для работы на моем ноутбуке. Точно такие же сценарии создали все три среды, и я мог бы расширить их для обработки новой среды / машины примерно за пять минут. Эта база данных включала в себя экстремальную настройку производительности, поэтому настройка всех соответствующих характеристик была абсолютно необходима.
Вернемся к продукту обработки страховых требований - позвольте мне добавить, что я был первоначально нанят, чтобы вести его преобразование из базы данных SQL Server в базу данных Oracle. Это преобразование было определено как бизнес-необходимость, поскольку большинство потенциальных клиентов не рассматривали продукт на базе SQL Server как профессиональное серьезное решение. Это не так часто встречается сегодня, но все же применяется в целом: программный продукт имеет больше шансов на проникновение на рынок, если он может работать с несколькими вариантами баз данных, как предпочитают целевые клиенты (особенно клиенты корпоративного класса).
Кроме того, установочный компакт-диск также рассматривался как существенный элемент. Однако эта и многие другие ситуации показали мне, что большинство «настоящих» администраторов баз данных не принимают установку баз данных на основе импорта. Как администратор баз данных и архитектор, я знаю, что определенно не буду по тем же причинам.
Проще говоря, установка базы данных на основе импорта практически не контролирует полученную базу данных. Это непрозрачно для клиента, оставляя его под сомнение, что он сделал. Это вынуждает клиента прилагать огромные усилия, чтобы попытаться использовать как можно меньше контроля. Он общеизвестно хрупок и подвержен ошибкам (импорт Oracle хорошо известен своими проблемами с правами собственности и разрешениями, проблемами с ограничениями и т. Д.). Принимая во внимание все эти последствия, установка базы данных на основе импорта непрофессиональна - она не ставит потребности клиентов на первое место.
Сценарии установки базы данных обеспечивают правильную прозрачность, конфигурируемость, выборочную повторяемость и общий контроль клиента, который требует профессионализм. Это также побуждает вас правильно понимать влияние ваших решений по разработке базы данных так, как это не делает импорт.
С наилучшими пожеланиями.