Особая забота / настройки для баз данных, которые попадают в несколько таблиц, в частности

Question

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

Если это не так, то предположим, что это на мгновение :) потому что в моем случае в нашей БД действительно всего 1-2 основных таблицы (примерно 20-30); а именно таблица клиентов.

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

Я отметил тег MySQL, но на самом деле любая информация о других методах, используемых с другими СУБД, все еще полезна.

Answer 1

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

• Вы хотите убедиться, что первичный ключ исправен. Обычно это целое число в автономере. Также убедитесь, что кластеризованный индекс основан на этом ключе. (это основные вещи, которые вы уже знаете, но я должен убрать их с дороги.)
• заменить повторяющиеся данные числами, относящимися к справочным таблицам, для производительности и целостности данных
• Используйте правильный тип данных, но наименьший из возможных, но не рискуйте с размером. (Это менее важно, чем для многих других вещей, если у вас нет огромных полей char везде, где будут числовые поля.)
• Индексы ! Вы должны иметь их. Подумайте о них при проектировании как об элементе вашей общей схемы, но они также могут быть применены гораздо позже, что даст большой эффект. Понять покрытые индексы. Клиенты звучит как нечто, с чем сталкиваются гораздо чаще, чем с обновлениями. Если да, то не стесняйтесь своих индексов.

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

• Ваши данные Нормализовано . Это ключ ко всему. Не беспокойтесь, если у вас будет множество таблиц с внешне связанными данными. Гораздо хуже то, что данные втираются не в 1032 1 к 1 в существующие таблицы. Современные БД отлично справляются с несколькими таблицами; но они не могут данные, относящиеся друг к другу неправильно.
• иметь хорошие, простые отношения внешнего ключа. Первый столбец в любой таблице обычно должен быть ключом автонумерации с именем, похожим на таблицу (CustomerID для таблицы Customers)
• прежде всего, ваши таблицы должны называться

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

Answer 2

Вы можете взглянуть на разбиение таблицы для очень больших таблиц.