Ух ты - у тебя впереди амбициозный проект. Определить, что такое хороший дизайн базы данных, невозможно, за исключением общепринятых принципов и руководств.
Вот несколько идей, которые приходят на ум:
Я работаю в компании, которая занимается управлением базами данных для нескольких крупных розничных компаний. У нас есть пользовательские базы данных, разработанные для каждой из этих компаний, в зависимости от того, как они намереваются использовать данные (для прямой почтовой рассылки, рассылок по электронной почте и т. Д.), И какие параметры анализа и выбора они предпочитают использовать. Например, компания, которая продает музыкальное оборудование в магазинах и в Интернете, будет хотеть проводить различие между покупателями и покупателями в Интернете, классифицировать покупателей по типу покупаемых ими предметов (барабаны, гитары, микрофоны, клавиатуры, записывающее оборудование, усилители, и т. д.) и отслеживайте, сколько они потратили и что купили за последние 6 месяцев или в прошлом году. Они используют эту информацию, чтобы решить, кто будет получать каталоги по почте. Эти рассылки очень дороги; может быть, один или два доллара на клиента, поэтому компания хочет, чтобы каталоги рассылались только тем, кто скорее всего что-то купит. У них может быть 15 миллионов клиентов в их базе данных, но только 3 миллиона покупают барабаны, и только 750 000 купили что-либо в прошлом году.
Если бы вы проанализировали созданную нами базу данных, вы найдете много «рабочих» таблиц, которые используются для конкретных целей выбора и которые могут на самом деле не разрабатываться должным образом в соответствии с принципами проектирования базы данных. В то время как «основные» таблицы разработаны эффективно и имеют надлежащие связи и индексы, эти «рабочие» таблицы могут создать впечатление, что вся база данных разработана плохо, тогда как в действительности рабочие таблицы могут использоваться несколько раз или даже только один раз, и мы еще не вошли, чтобы очистить их или бросить их. Рабочие таблицы намного превосходят основные таблицы в этой конкретной базе данных.
Также необходимо учитывать объем управляемых данных. Клиентская база в 10 миллионов может иметь данные о транзакциях от 10 до 20 миллионов транзакций в неделю. Или за день. Иногда для удобства управления эти данные должны быть разбиты на таблицы по диапазону дат, а затем представление будет использоваться для выбора данных из соответствующей вложенной таблицы. Это эффективно для такого огромного объема, но может показаться повторяющимся для автоматического анализатора.
Ваш анализатор должен быть настроен пользователем до начала анализа. Некоторые элементы должны быть пропущены, в то время как другие могут быть абсолютно критическими.
Кроме того, как анализировать хранимые процедуры, пользовательские функции и т. Д.? Я видел действительно ужасный код, который работает довольно эффективно. И некоторые из самых уродливых, неэффективных кодов были написаны только для одноразового использования.
Хорошо, у меня нет идей на данный момент. Удачи в вашем проекте.