РСУБД используют совершенно другой подход к хранению данных, чем объектные базы данных или базы данных типа "ключ-значение".
Реляционная модель предполагает, что вы не знаете, какие данные потребуются в будущем или как к ним будет осуществляться доступ в будущем. Это оказалось довольно надежным предположением на моем опыте.
Это одна из причин, по которой СУБД SQL позволяет добавлять индексы по мере необходимости и позволяет удалять индексы, которые оказались бесполезными. Это позволит вам добавлять ограничения по мере их появления — ограничения, которые иногда требуют добавления дополнительных таблиц — и удалять ограничения по мере изменения требований. Это позволит вам добавлять столбцы по мере того, как вы обнаружите больше вещей, которые было бы полезно знать. Это позволит вам заменить таблицы представлениями и заменить представления таблицами. Некоторые СУБД позволяют создавать материализованные представления — их влияние на скорость запросов может быть значительным, а на использование дискового пространства — разрушительным.
Полезные базы данных расширяют сферу их действия. База данных SQL, разработанная в соответствии с реляционной моделью, позволяет относительно легко добавлять функции, о которых никто и не мечтал во время первоначального проектирования, и без разрушения других частей системы. Поэтому их часто призывают делать вещи, которые их первоначальные дизайнеры не могли себе представить.
Все эти вещи
- добавление и удаление индексов с течением времени,
- добавление и удаление ограничений с течением времени,
- добавление и удаление столбцов с течением времени,
- добавление и удаление таблиц с течением времени,
сделать любую оценку использования диска пустой тратой времени. Любой из них сам по себе может кардинально изменить дисковое пространство, необходимое для базы данных.
Вы можете довольно точно рассчитать пространство, необходимое для строки и страницы. (Попробуйте Google для «Макет строки YourDBMSname» и «Макет страницы YourDBMSname».) Но когда вы пытаетесь умножить на количество требуемых строк, вы должны оценить количество строк. Это ставит вас на большой конец того, что Стив МакКоннелл называет "конусом неопределенности".
Если вы не измеряли использование дискового пространства в нескольких проектах в вашей собственной компании с течением времени, оценка влияния этих пунктов, приведенных выше, является лишь предположением.
У последней компании из списка Fortune 100, в которой я работал, была рабочая база данных, которая работала с 1970-х годов. Сотни приложений, написанных более чем на 25 языках программирования в течение 40 лет, ежедневно попадают в эту цель. (Я думаю, что изначально он был построен на IMS от IBM; сегодня он работает на Oracle.)
Еще несколько лет назад никто не предполагал, что их база данных будет использоваться для перевода технических чертежей и спецификаций на китайский язык, а также для изготовления таможенных документов, необходимых для вывоза готовой продукции из Китая. Внедрение этих новых функций требовало хранения дополнительных данных о каждой детали и о каждом проектном документе в их оперативной инвентаризации. В начале этого проекта наши оценки были довольно далекими. Это большой конец конуса. (Мы оценили несколько вещей, но не использование диска. От нас требовалось добиться успеха, поэтому, какой бы дизайн я ни придумал, кто-то должен был предоставить необходимое дисковое пространство.) Но когда мы запускались, мы знали точное значение для каждого оценка, потому что мы уже сделали работу. (Это узкий конец конуса.)
Итак, как снизить риск догадок в среде проектирования и развертывания базы данных? Извлеките урок из 1972 года.
Создайте прототип и измерьте его.
Инженеры-химики давно усвоили, что процесс, работающий в лаборатории, не может быть реализован на заводе всего за один шаг. Промежуточный этап, называемый пилотным заводом, необходим, чтобы получить опыт увеличения объемов производства и работы в незащищенных средах. . . .
. . . Проект за проектом разрабатывают набор алгоритмов, а затем погружаются в создание программного обеспечения для клиента в соответствии с графиком, который требует доставки первой созданной вещи. . . .
Таким образом, вопрос управления заключается не в том, стоит ли построить пилотную систему и выбросить ее. Вы будете это делать. Вопрос только в том, планировать ли заранее создание одноразового товара или обещать доставить его покупателям.
Фред Брукс-младший, Мифический человеко-месяц, стр. 116.
person
Mike Sherrill 'Cat Recall'
schedule
03.03.2012
