Когда длина кортежа слишком велика?

Question

Вот логическая схема для моего самого большого отношения:

{(id, uName, supplies, score, playerType, storageSupplies, supplyDrop, barracks, armourDepot, hangar, droneHangar, storage, offensive, defensive, infantry, vehicles, air, fuel, explored, morale, cash, population, tax, food, aSector, cSector, iSector, XP)}

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

Answer 1

Внутреннее представление таблицы имеет максимальный размер строки 65 535 байт.

Эффективность зависит от версии MySQL и используемого вами механизма хранения.Но вы должны знать, что это увеличит объем кэшируемых данных, которые могут быть необязательными.

Например, таблица Users может увеличиться, если мы добавим адресные данные пользователей, и эти данные могут быть не нужныпоэтому разделение его на 2 таблицы: Users и Users_address будет более эффективным, поскольку, если таблица «Пользователи» интенсивно читает, она может быть кэширована.

Answer 2

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

2)Каждый маленький бит имеет значение;например, с таблицей эта маленькая большая часть может быть сохранена в памяти, и у вас будет очень быстрый ВЫБОР;если многие атрибуты в основном равны NULL, то разделение таблицы уменьшит ее размер и освободит ОЗУ для других кэшей;уменьшить количество необходимых операций ввода-вывода при обновлении (как правило, сделать вещи более масштабируемыми).Это приводит к незначительному увеличению сложности (для обновлений SELECTS может использовать VIEW).

3) «Накладные расходы» для разделения отношений «один к одному» - неправильное представление;это в значительной степени зависит от рабочей нагрузки - вы можете создавать дела, которые предпочитают вещи, разбитые на две меньшие таблицы, и вы можете создавать дела, которые выигрывают от хранения данных в одной таблице.