Насколько разумны базы данных, такие как MySQL и H2, когда дело доходит до минимизации избыточности?

Question

Я новичок в базах данных, и этот вопрос связан с тем, насколько умным я могу ожидать, что базы данных будут.Здесь под «базами данных» я подразумеваю «что-то вроде» MySQL или H2 (на самом деле я понятия не имею, похожи ли эти два, просто они популярны).Я на самом деле использую ScalaQuery, поэтому он абстрагируется от базовой базы данных.

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

(Адам, 18) (Адам, 24) (Адам, 34) ... продолжение ... (Адам, 3492) (Бетани, 4) (Бетани, 45)... продолжение ... (Бетани, 2842)

Если я сохраню эту таблицу с H2, она будет достаточно умной, чтобы понять, что "Адам" и "Бетани" повторяются много раз и могутбыть заменены перечислениями, указывающими на таблицы поиска?Или это приведет к потере большого количества памяти?

В связи с этим: если Н2 умен в этом отношении со строками, то он также умен так же, как и с двойными?В моей, вероятно, мертвой исходной таблице у меня много повторяющихся двойных полей.

Спасибо!

Answer 1

Ядро базы данных не создано для распознавания избыточных данных и их исправления. Это задача дизайнера / разработчика.

Answer 2

Базы данных предназначены для хранения информации.Нет никакого способа, которым база данных будет знать, могут ли (Адам, 44) и (Адам, 55) быть сжаты, и я был бы ошеломлен, если бы базы данных пытались сделать то, что вы предлагаете, поскольку это может привести к различной производительности и / илипроблемы.

Напротив, базы данных не минимизируют хранилище, они добавляют избыточную информацию, такую ​​как индексы и ключи, и другую внутреннюю дополнительную информацию, необходимую для БД.

БД созданы для быстрого получения информации, а не для ее эффективного хранения.Когда дело доходит до сложности, база данных скорее увеличивает объем памяти, а затем снижает производительность запроса.

Answer 3

Есть несколько систем хранения, которые сжимают страницы, поэтому вопрос правильный.Я не могу говорить о MySQL, но я считаю, что он похож на H2.H2 не очень умен в этом отношении.H2 сжимает данные, но только в следующих случаях:

• Сжатие большого объекта , если включено.
• Следующее не влияет на размер хранилища закрытая база данных: H2 сжимает журнал отмены при записи, используя LZF в настоящее время, поэтому повторяющиеся данные на странице приведут к немного улучшенной производительности записи (но только после контрольной точки).Однако в будущем это может измениться.

Кроме того, H2 использует код, аналогичный UTF-8, для хранения текста, но я бы не назвал это сжатие.

Answer 4

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

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

Answer 5

MySQL и другие продукты SQL, основанные на непрерывном хранилище, совсем не умны в этом.

Рассмотрим два логических набора, один из которых ссылается на другой (т. Е. Внешний ключ). Одна возможная реализация состоит в том, чтобы физически хранить значение, общее для обоих наборов, только один раз, и для обеих таблиц хранить указатель на значение (представьте переменные ссылочного типа в языках программирования 3GL, таких как C #). Однако большинство продуктов SQL физически хранят значения в обеих таблицах; если вам нужны указатели, то конечный пользователь должен реализовать их самостоятельно, обычно используя целочисленные «суррогатные» ключи автоинкремента, которые, к сожалению, попадают в логическую модель.