Каковы общие подводные камни при разработке новой базы данных SQL? - PullRequest
3 голосов
/ 04 июня 2009

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

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

Сначала вопросы в моей базе данных, которые привели меня к пониманию, что я недостаточно знаю:

  1. Как мне обеспечить актуальность моих таблиц ссылок «многие ко многим» и столбцов «один ко многим» при внесении изменений в ссылочные таблицы? С какими проблемами я могу столкнуться?
    • Я использую nvarchar (n) и nvarchar (MAX) для различных текстовых полей. Стоит ли вместо этого использовать эквиваленты varchar (я читал, что при использовании nvarchar могут быть риски производительности)? Есть ли еще какие-то ошибки, касающиеся выбора типов данных, помимо осторожности в использовании массивов символов фиксированной длины для хранения информации переменной длины? Любые правила о том, как выбрать соответствующий тип данных?
    • Я использую int для столбца ID каждой таблицы, который является моим первичным ключом во всех, кроме таблиц ссылок (где у меня есть два первичных ключа, ID s строк ссылочной таблицы). Этот идентификатор устанавливается как личность. Есть ли подводные камни в этом подходе?
    • Я создал таблицы метаданных для таких вещей, как типы юнитов и статусы, но я не знаю, правильно ли это было делать или нет. Вы должны создать новые таблицы для таких вещей, как нумерованные списки, или есть лучший способ?

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

Сообщество wiki'd из-за довольно субъективной природы подобных сообщений. Извиняюсь, если это дубликат, я провел несколько поисков чего-то подобного, но не смог найти ни одного, хотя этот, безусловно, связан . Спасибо.

Обновление

Я только что нашел этот вопрос , который очень похож окольным путем.

Ответы [ 8 ]

3 голосов
/ 04 июня 2009
  1. Нормализуется
  2. Не используется нормализация
  3. Попытка реализовать денормализованную схему с самого начала

Серьезно:

  1. Внешние ключи будут запрещать удаление или обновление из родительских таблиц. Или их можно каскадировать.

  2. Как можно меньше: 2 последних вопроса SO типы данных и (n) varchar

  3. Может быть не переносимым, и ваш «естественный ключ» (скажем, «название продукта») все еще нуждается в уникальном ограничении. В противном случае нет, но помните, что столбец IDENTITY является « суррогатным ключом »

Редактировать: скажем, вы ожидаете хранить фрукты с колонками FruitID и FruitName. У вас нет возможности ограничиться одним появлением «Apple» или «Orange», потому что, хотя это ваш «естественный ключ», вы используете суррогатный ключ (FruitID). Таким образом, для поддержания целостности вам нужно уникальное ограничение на FruitName

  1. Не уверен или ваш смысл, извините. Редактировать: Не делай этого. Ye olde " Одна истинная таблица поиска " идея.
2 голосов
/ 04 июня 2009

Я отвечу на ваш субъективный запрос с некоторыми неопределенными обобщениями. :)

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

Вот несколько вопросов для размышления.

Что обновляется чаще всего? Сохраняет ли эта таблица блокировку записи для блокировки запросов? Станет ли это горячей точкой? Даже, казалось бы, хорошо нормализованная схема может быть плохой, если вы не понимаете отношения чтения и записи.

Какие нужны внешние интерфейсы? Я участвовал в проектах, где пунктирная линия к «этой другой системе» почти затопила весь проект, потому что его реализация была отложена до тех пор, пока все остальное не было на месте, то есть все остальное было негибким.

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

Просто о чем подумать.

1 голос
/ 05 июня 2009

Я также новичок в разработке баз данных, но я нашел этот онлайн-учебник очень, очень полезным:

Разработка базы данных с использованием UML и SQL, 3-е издание

Автор объясняет все основные аспекты проектирования базы данных, и очень ясно. Прежде чем я нашел это онлайн-руководство, я много читал в Википедии о нормализации. Хотя это помогло, этот автор объясняет точно такие же вещи (по крайней мере, через 3-ю обычную форму), но гораздо, гораздо проще для чтения. Он в значительной степени отвечает и на все ваши вопросы.

1 голос
/ 04 июня 2009

Вы можете найти некоторые полезные вещи на этих слайдах: [http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back][1]

1 голос
/ 04 июня 2009

Звучит так, будто вы хорошо понимаете, что вы должны делать, и на самом деле не существует «одного истинного пути» к работе с базами данных.

Вы установили каскады для своих иерархических объектов (т. Е. Одно удаление в «заголовке» вашего объекта в базе данных удалит все записи в таблицах, относящихся к этой записи)?

Ваши таблицы ссылок и столбцы 1: n должны быть внешними ключами, поэтому не стоит беспокоиться об изменении данных. Под "двумя первичными ключами" вы имели в виду индексы?

Что касается таблиц метаданных, я делал их в прошлом и не делал. Одного статуса символа с комментарием SQL может быть достаточно для ограниченного набора статусов, но за пределами определенного количества или когда вы можете подумать о добавлении большего в будущем, вы можете захотеть ссылаться на другую таблицу метаданных, или, возможно, символ (8ish). Например, я видел, что пользовательские таблицы имеют «NORMAL», «ADMIN», «SUPER», «GUEST» и т. Д. Для типа пользователя, который мог быть 1,2,3,4,5 fkeys для таблицы «UserType» , но при таком ограниченном перечислении это имеет значение? Вместо этого у других людей есть таблица разрешений (логические значения, которые может делать пользователь) - множество способов убрать кошку из кожи.

0 голосов
/ 09 июня 2009

Помимо прочего, не используя первичные ключи, не думая заранее о том, будете ли вы использовать индексированные представления (и разрабатывать соответствующие таблицы; мне когда-то приходилось удалять и заново создавать большую таблицу на моем сайте, чтобы изменить ее атрибут ANSI_NULL на ON чтобы я мог затем использовать его с индексированным представлением), используя индексы.

0 голосов
/ 04 июня 2009

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

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

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

0 голосов
/ 04 июня 2009

Я бы предложил хорошую книгу. Лучшее ИМО это:

http://www.amazon.com/Server-2005-Database-Design-Optimization/dp/1590595297/ref=ntt_at_ep_dpt_1

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...