Правила для начинающих администраторов баз данных, которым необходимо следовать при разработке таблиц - PullRequest
1 голос
/ 27 июня 2011

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

  • Как спроектировать таблицу [с более читаемым, меньше записываемым / менее читаемым, больше сценарием записи] ?
  • Какие распространенные ошибки делают начинающие при разработке таблиц?
  • И, если возможно, несколько примеров.

Ответы [ 2 ]

4 голосов
/ 27 июня 2011

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

  • Используйте соответствующие типы данных - не сохраняйте дату в строковом поле - не сохраняйте числовые значения в строковом поле (я видел все это уже сделано!) ; если ваши строки длиной 60-100 символов - не используйте VARCHAR(MAX) (2 ГБ) в SQL Server ..... если у вас есть строки фиксированной длины (например, коды) длиной менее 5 символов - используйте CHAR(x) not VARCHAR(x) и т. Д ....

  • Нормализуйте ваших данных - попробуйте получить третью нормальную форму - и затем денормализуйте, где это необходимо и уместно. Но сначала дизайн до 3NF уровней нормализации. Это также означает: каждая таблица имеет четко определенный первичный ключ.

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

  • Тщательно подумайте о вашем доступе к запросу - какие таблицы будут запрашиваться как? Подумайте о возможных показателях - но не переусердствуйте! Слишком много индексов может быть хуже, чем вообще никаких. Найти баланс.

Плюс есть некоторые специфические оптимизации для конкретного производителя.

т.е. в SQL Server я бы:

  • всегда ставит индекс для полей внешнего ключа - это помогает с JOIN и ускорением обеспечения ссылочной целостности

  • часто перемещают большие поля больших двоичных объектов (VARCHAR(MAX), VARBINARY(MAX)) в отдельные таблицы и связывают их с «базовыми» таблицами. Таким образом, если вы используете, например, ORM, вы не будете загружать все эти огромные блоки байтов в память все время.

Эта статья Основы проектирования реляционных баз данных Пола Литвина довольно хорошо подводит итог.

2 голосов
/ 27 июня 2011

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

Оперативная база данных

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

База данных отчетов

Эта база данных (хранилище данных) оптимизирована для операций только чтения. Это будет деноморализовано и часто как схема звезды.

Промежуточная база данных

Если вам нужно несколько приложений для доступа к вашим данным. Вы можете создать промежуточную базу данных, в которой есть копия всех данных в вашей операционной БД. Основное отличие состоит в том, что в этой БД не должно быть никаких ИНДЕКСОВ или множества ограничений, триггеров и т. Д., Поскольку все они замедляют операции ВСТАВКИ (записи). Эта БД просто используется как временное хранилище для БЫСТРОГО извлечения всех производственных данных, но никакое другое приложение не должно работать напрямую с этой БД. Другие приложения должны извлекать из них необходимые данные и помещать их в свой собственный формат. Например, скопируйте данные из промежуточного этапа в хранилище отчетов / данных. Его основное назначение - снизить нагрузку на оперативную базу данных.

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

...