Лучше всего иметь сотни столбцов или разделять на несколько таблиц?
Вы можете использовать ловушку жизненного цикла shouldComponentUpdate(nextProps, nextState). Вы пишете логику для проверки значения ваших свойств и состояния, после проверки возвращаете true для повторной визуализации компонента, в противном случае возвращаете false, чтобы запретить повторную визуализацию компонента. Подробнее о них читайте в их официальных документах .
или вы можете использовать React.PureComponent вместо React.Component, если вы хотите, чтобы React обрабатывал логику повторного рендеринга, сравнивая все старые и новые реквизиты и значения состояний за занавесом.
6 ответов
Я думаю, что мы должны знать больше о Вашем дизайне для ответа правильно. Например, мне любопытно, что могло быть много столбцов, касающихся неправильного функционирования, партии (различных) касающийся заторов и т.д. (Не затор просто своего рода неправильное функционирование так или иначе?)
Ваш дизайн нормализован? По-видимому, у Вас нет столбцов как "jam1", "jam2", и т.д.?!
Принятие дизайна хорошо и нормализовано, решение относительно того, иметь ли одну широкую таблицу, или много более узких компромисс между различными факторами:
- Все/больше всего записи имеют статистику всех типов? Да => одна таблица, нет => многие
- Необходимо ли часто запрашивать статистику всех типов вместе? Да => одна таблица, нет => многие
- Вы поддерживаете всю другую статистику вместе на том же экране? Да => одна таблица, нет => многие
- Вы, вероятно, поразите какие-либо пределы базы данных, например, макс. 1 000 столбцов за таблицу?
Какой бы ни путь, которым Вы идете, можно использовать представления для представления альтернативной структуры для удобства разработчика:
- Одна таблица: много представлений, что избранная статистика конкретных типов
- Много таблиц: представление, которое присоединяется ко всем таблицам вместе
Обновление
Из Ваших комментариев я теперь знаю, что у Вас есть количества заторов в 40 различных местах на машине, и другие типы статистики являются количествами аналогичного характера. Это предлагает дизайн следующей таблицы:
create table machines (machine_id ... primary key, ...);
create table machine_stats
( machine_id references machines
, stat_group -- 'jams', 'malfunctions' etc.
, stat_name -- 'under the hood', 'behind the door' etc.
, stat_count
);
Как кто-то прокомментировал ниже, они позволяют Вам суммировать статистику более легко - в или через типы статистики. Это также легко расширяется, если новая статистика должна быть добавлена к типу статистики.
Когда я вижу сотни столбцов в таблице, я склонен подозревать, что схема данных не была правильно нормализована. Сотни столбцов действительно уникальны, или являются ими группы подобных вещей, которые могут быть нормализованы в меньшие таблицы?
Если можно сократить количество столбцов, Вы склонны уменьшить общий объем проведенных данных и следовательно улучшить производительность на многих уровнях. Например, если у Вас есть запись, которая содержит 1 000 байтов данных, и Вы хотите измениться на 1 байт для каждой записи, Вы рискуете выбирать и хранить 999 байтов излишне. Это действительно влияет на производительность.
Вы имеете в виду 100 с типов статистики?
Некоторые медицинские базы данных попробовали схему или идиому, которую называют "значением атрибута объекта" или "EAV" (Вы можете Google эти условия): обоснование состоит в том, что существуют неисчислимые различные типы факта о пациенте, который может или не мог быть получен ни для какого данного пациента, и что EAV является лучшим способом сохранить это, чем иметь неисчислимые различные столбцы в таблице.
Остерегайтесь однако, что EAV спорен: некоторые говорят, что это - "запах кода" и типичная ошибка новичка; другие говорят, что это иногда полезно (или редко), но зависит от (определение и наличие) хорошая поддержка метаданных.
Нормализация гарантирует, чтобы Вы не повторяли данные в своей схеме.
Существуют пределы тому, как далеко необходимо пойти, конечно. СОЕДИНЕНИЯ для 7 таблиц или больше не производительно.
Но одна таблица монстра? Я разбил бы его.
Я склонен не любить таблицы со слишком многими столбцами. Одна возможность, которую Вы могли бы рассмотреть, состоит в том, чтобы сохранить статистику как строки в таблице статистики:
CREATE TABLE Statistics (id AS INTEGER PRIMARY KEY, statusType As VarChar,
statusValue As Float);
Затем Вы просто добавляете новую строку с для каждого состояния, которое Вы отслеживаете. Это намного более чисто с точки зрения DB, но она действительно делает достигание данных более коварным для отчетов.
В этой ситуации я составил бы несколько таблиц. Можно было бы быть таблицей машины. Можно было бы быть проблемной справочной таблицей. Наконец, объединяющая таблица между двумя, которая также содержит информацию, имела отношение к состоянию. Обслуживание будет легче, и пишущие сумасшедшие отчеты будут легче. Кроме того, добавление новых типов состояний будет легче также.
machine
id
name
description
status_flag
id
caption
machine_history
machine_id
status_flag_id
information
Затем можно сделать материал как: выберите количество (отличный machine_id) от machine_history где status_flag_id = 23 и информация <5;
Единственной вещью является информационное поле в machine_history таблице, возможно, должен содержать числа или символы. Если это так, я создал бы два информационных поля так, чтобы Вы не препятствовали производительности.
Также я предполагаю, что существует компонент программирования к этому, которое позволит Вам создавать некоторые методы для того, чтобы легко работать с этими данными.