Как рассчитать затраты на создание базы данных?

СУБД используют совершенно иной подход к хранению данных, чем базы данных объектов или ключей.

реляционная модель предполагает, что вы не знаете, какие данные будут нужны в будущем, или, как данные будут доступны в будущем. Это оказалось довольно надежным предположением из моего опыта.

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

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

все эти вещи

• добавление и удаление индексов с течением времени,
• добавление и удаление ограничений во времени,
• добавление и падение столбцов с течением времени,
• добавление и удаление таблиц с течением времени,

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

вы можете вычислить пространство, необходимое для строки и страницы довольно точно. (Попробуйте Google для "yourdbmsname макет строки "и"yourdbmsname макет страницы".) Но когда вы пытаетесь умножить на количество требуемых строк, вы должны оцените количество строк. Это ставит вас в большой конец того, что Стив Макконнелл называет"конус неопределенности".

Если вы не измеряли использование диска в нескольких проектах с течением времени в вашей собственной компании, оценка влияния этих маркеров выше-это просто догадка.

последняя компания Fortune 100, в которой я работал, имела операционную базу данных, которая была в производстве с 1970-х годов. Сотни заявок, написанных более чем в 25 языки программирования в течение 40 лет каждый день. (Я думаю, что изначально он был построен на IMS IBM; сегодня он работает на Oracle.)

Итак, как вы снизить риск догадок в среде разработки и развертывания баз данных? Возьмите урок 1972 года.

создайте прототип и измерьте его.

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

. . . Проект за проектом проектирует набор алгоритмов, а затем погружается в строительство программного обеспечения для заказчика по графику, который требует поставки первой построенной вещи. . . .

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

Фред Брукс-младший, в Мифический Человек-Месяц, стр. 116.