Шаблоны баз данных

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

@Gaius,

Это вопрос, который должен оценивать разработчик базы данных - какова вероятная стабильность структуры базы данных? Учитывая достаточно длинный горизонт, ничто не стабильно. Или сказать обратное, учитывая достаточно длинный горизонт, все может измениться. Суррогатный ключ (теоретически) никогда не должен меняться, потому что никогда не имел смысла начинать.

Я предполагаю, что другая вещь, которую следует учитывать в этом конкретном сценарии проектирования, - кто это, кто будет видеть первичный ключ? Если первичный ключ - это то, что конечные пользователи действительно должны будут ссылаться, тогда имеет смысл сделать это чем-то, что они могут понять. Но я не могу думать о многих случаях, когда конечный пользователь должен видеть первичный ключ; обычно используется первичный ключ, позволяющий механизму БД ускорять определенные операции.

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

Ответ 1

В частности, относительно ключей: я категорически не согласен со странной мыслью, что ключи должны быть без смысла. В целом, я считаю базу данных совокупностью фактов; как только вы начнете добавлять в него произвольные номера (например, сгенерированные ключи) и другую нерелевантную информацию, это должен быть предупреждающий знак. Я рекомендую это сокрушительно Джо Целько для получения дополнительной информации о ключах.

Более общие примечания:

Предложения по схемам проектирования/модели данных для разных предприятий: Дэвид С. Хей: модели данных: условные обозначения мысли Довольно старый, но есть причина, по которой он все еще печатается
http://www.dorsethouse.com/books/dmp.html

Возможно, не очень похож на рисунок, но все же очень хорош: Стефан Фарул, Питер Робсон: Искусство SQL http://oreilly.com/catalog/9780596008949/

Еще один, который я могу порекомендовать: Вадим Тропашко: шаблоны проектирования SQL - экспертное руководство по программированию SQL http://www.rampant-books.com/book_2006_1_sql_coding_styles.htm

Систематический учебник по моделированию данных: Graeme Simsion и Graham Witt, "Основы моделирования данных", http://www.elsevierdirect.com/product.jsp?isbn=9780126445510

Возможно, вы действительно ищете "руководство по стилю"?. В этом случае: Джо Селко: стиль программирования SQL http://www.elsevierdirect.com/product.jsp?isbn=9780120887972

Ответ 2

Книги E.F. Codd и C.J. Date - наиболее очевидные ответы. Я не читал эту книгу, но я знаком с авторами, это, скорее всего, неплохо.

Прикладная математика для профессионалов баз данных Лекс де Хаан и Тоон Коппелаарс.

Ответ 3

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

Итак, если у меня есть, например, таблица счетов-фактур и таблица InvoiceDetail, мы, вероятно, можем использовать InvoiceNumber в качестве нашего первичного ключа на первом. Он уже существует в наших данных и (предположим?) Был бы уникальным. Для второй таблицы мы, вероятно, будем застревать, нуждаясь в суррогатном ключе, однако, независимо от того, присоединился ли он к номеру счета как составному или нет.

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

- Кевин Фэрчайлд

Ответ 4

Чтобы точно ответить: да. Есть * * -тоны информации, написанные на "хорошем" дизайне базы данных. Несмотря на то, что примерное эмпирическое правило, безусловно, вызывает сомнения.

Ответ 5

SQL Anti-Patterns, написанный Биллом Карвином, очень легко читать (не сухим) и объясняет в довольно ясных терминах ряд различных потенциальных ошибок, как вы можете использовать их, и как/почему делать все правильно.

Ответ 6

Использование первичных ключей с бизнес-значением ( "естественные ключи" ), безусловно, имеет свои достоинства, но может затруднить реорганизацию вашей базы данных. Соблюдайте осторожность, особенно если есть основания полагать, что структура базы данных со временем изменится.