Блог

Главная - Вопросы по программированию - Будет ли таблица «String» экономить место в моей базе данных Access?

Будет ли таблица «String» экономить место в моей базе данных Access?

#ms-access

#ms-access

Вопрос:

Я разрабатываю базу данных Access, которая в сочетании с библиотекой классов C # позволит мне хранить и извлекать объекты с произвольными типами данных. База данных будет вести себя примерно как хранилище EAV (Entity / Attribute / Value), где запись для каждого значения будет ссылаться на имя сущности, имя атрибута и тип данных (а также фактические данные, хранящиеся в виде сериализованной строки JSON (Javascript Object Notation).

Из-за особенностей базы данных я буду использовать одни и те же строки снова и снова. Например, многие записи будут иметь строку «System.Double» хранится в поле типа данных. Поэтому я думаю об экономии места путем записи этих строк в таблицу с автоинкрементным целочисленным первичным ключом, который будет использоваться вместо прямого использования строк. Так, например, вместо того, чтобы иметь…

 CREATE TABLE [Value] (
    ...
    [DataTypeName] VARCHAR NOT NULL,
    ...);

… Я бы так и сделал…

 CREATE TABLE [Name] (
    [NameID]    AUTOINCREMENT PRIMARY KEY,
    [NameValue] VARCHAR NOT NULL UNIQUE);

CREATE TABLE [Value] (
    ...
    [DataTypeNameID] INTEGER NOT NULL REFERENCES [Name],
    ...);

Будет ли это хорошим подходом, или в базах данных Access встроено сжатие строк для повторяющихся строк?

Комментарии:

1. Я бы сказал, что «поддерживаемые типы данных» являются частью кода, а не частью пользовательских данных. Таким образом, я бы предложил третий подход: в вашем коде определите перечисление, содержащее все поддерживаемые вами типы данных (т. Е. Те, В которых ваша библиотека знает, как их упорядочивать / разархивировать), и просто сохраните значение перечисления в базе данных.

2. @Heinzi дело в том, что поддерживаемые типы данных могут и будут меняться с течением времени, что привело меня к этому методу хранения данных. Использование значения enum будет просто запутанным, поскольку потенциально будут храниться сотни различных типов данных.

3. Я вижу, имеет смысл. Я действительно считаю, что ваш метод «кэширования» типов данных сэкономит место (т. Е. В Access нет встроенного сжатия строк), но это всего лишь интуиция, поэтому я с нетерпением жду ответа на ваш вопрос. В любом случае помните о высказывании «преждевременная оптимизация — корень всего зла» — достаточно ли велика разница, чтобы иметь значение на практике (и стоит усилий и дополнительной сложности)?

4. @Heinzi: «Access не имеет встроенного сжатия строк» — по иронии судьбы, движок имеет сжимаемые текстовые типы данных начиная с Jet 4.0 около 2000 года.

5. например, @onedaywhen позволяет избежать «грязных» данных из-за ошибок в написании одного и того же значения, например ‘System. Double’ и ‘System-Double’, если задействован какой-либо ручной ввод данных; это расширяет возможности использования элементов формы доступа, таких как поля со списком; он предоставляет индекс допустимых значений.