СУБД использовать совершенно другой подход к хранению данных, чем объект или ключ-значение базы данных.
Реляционная модель предполагает, что вы не знаете, какие данные понадобятся в будущем или как данные будут доступны в будущем. Это оказалось довольно надежным предположением в моем опыте.
Это одна из причин, по которой SQL dbms позволит вам добавлять индексы по мере необходимости и позволяет отказаться от индексов, которые оказались бесполезными. Это позволит вам добавлять ограничения по мере их появления - ограничения, которые иногда требуют добавления дополнительных таблиц, - и ограничения на падение по мере изменения требований. Это позволит вам добавлять столбцы, поскольку вы обнаружите больше вещей, которые было бы полезно знать. Это позволит вам заменять таблицы на представления и заменять представления таблицами. Некоторые dbms позволят вам создавать материализованные представления - их влияние на скорость запросов может быть драматичным, а их влияние на использование диска - разрушительным.
Полезные базы данных расширяют свои возможности. База данных SQL, разработанная в соответствии с реляционной моделью, позволяет относительно легко добавлять функции, о которых никто не мечтал во время первоначальной разработки, и без дробления других частей системы. Поэтому их называют часто призванными делать то, что их первоначальные дизайнеры не представляли.
Все эти вещи
- добавление и удаление индексов в течение долгого времени,
- добавление и удаление ограничений во времени,
- добавление и удаление столбцов с течением времени,
- добавление и удаление таблиц с течением времени ,
оценивать использование диска как пустую трату времени. Любой из них может существенно изменить дисковое пространство, необходимое для базы данных.
Вы можете точно рассчитать пространство, требуемое строкой и страницей. (Попробуйте Google для «Макет строки YourDBMSname» и «Макет страницы YourDBMSname».) Но когда вы пытаетесь умножить на количество требуемых строк, вам нужно оценить количество строк. Это ставит вас в большой конец того, что Стив Макконнелл называет «cone of uncertainty».
Если вы не измеряли использование дискового пространства в нескольких проектах со временем в своей собственной компании, оценка воздействия указанных выше пунктов указывает только на догадки.
Последняя компания Fortune 100, в которой я работала, имела операционную базу данных, которая была в производстве с 1970-х годов. Сотни приложений, написанных более чем на 25 языках программирования в течение 40 лет, ежедневно попадали в эту вещь. (Я думаю, что он был построен на базе IMS от IBM, сегодня он работает на Oracle.)
Даже несколько лет назад никто не представлял, что их база данных будет использоваться для перевода инженерных чертежей и материалов материалов на китайский язык и также для производства таможенных документов, необходимых для получения готовой продукции из Китая. Внедрение этих новых функций потребовало хранения дополнительных данных о каждой части и каждого проектного документа в их живом инвентаре. В начале этого проекта наши оценки были довольно далекими. Это большой конец конуса. (Мы оценили несколько вещей, но не использование диска. Мы должны были добиться успеха, поэтому, независимо от того, с каким дизайном я пришел, кто-то должен был предоставить необходимое дисковое пространство.) Но когда мы вышли вживую, мы знали точное значение для каждого Оцените, потому что мы уже выполнили эту работу. (Это узкий конец конуса.)
Итак, как вы уменьшаете риск догадок в среде проектирования и развертывания базы данных? Проведите урок с 1972.
Постройте прототип и измерьте его.
Инженеры-химики узнали давно, что процесс, который работает в лаборатории не может быть реализован на заводе только один шаг. Промежуточный этап , который называется экспериментальной установкой , необходим для получения опыта по масштабированию величин вверх и при эксплуатации в незащищенных средах . , , ,
. , , Проект после проекта проектирует набор алгоритмов, а затем погружается в построение программного обеспечения, поставляемого заказчиками, по расписанию, которое требует доставки первой вещи. , , ,
Вопрос управления, следовательно, не является ли для создания пилотной системы и выбросить ее. Вы будет сделайте это. Вопрос только в том, планировать ли заранее, чтобы построить бросок, или обещать доставить заказным клиентам.
Фред Брукс младший, в Мифический человеко-месяц, стр 116.
Почему вы хотите, чтобы вычислить, что при разработке схемы .. это звучит как необоснованный вещь, чтобы попробовать, так как сама схема не будет определять размер базы данных. Также учитывая, что стоимость пространства для хранения будет наименее важным фактором для общей стоимости, например. выбрав нужную базу данных. –
@ManfredMoser, схема базы данных - это плоть вашего приложения. Как он построен, показывает, какие ваши планы предназначены для хранения данных. – Xeoncross
Да ..но много других факторов существенно повлияет на хранение, так что любая оценка из схемы сама по себе без дополнительных требований, таких как производительность (кэширование, индексы ..) или запрос (хранилище данных поверх OLTP) становится совершенно бессмысленной ... imho вы тратя ваше время. –