MySQL Datefields: дублировать или рассчитать? - PullRequest
Новая
       7

MySQL Datefields: дублировать или рассчитать?

1 голос
/ 01 июня 2010

Мы используем стол со структурой, навязанной нам более 10 лет назад. Нам разрешено добавлять столбцы, но настоятельно рекомендуется не изменять существующие столбцы .

Некоторые столбцы предназначены для представления дат, но представлены в другом формате. Среди прочих: 

 * CHAR(6): YYMMDD
 * CHAR(6): DDMMYY
 * CHAR(8): YYYYMMDD
 * CHAR(8): DDMMYYYY
 * DATE
 * DATETIME

Поскольку теперь мы хотели бы выполнять более сложные запросы, используя расширенные функции даты, мой менеджер предложил продублировать эти проблемные столбцы в правильный столбец FORMATTED_OLDCOLUMNNAME, используя формат DATE или DATETIME.

Это путь? Не могли бы мы просто использовать функцию STR_TO_DATE каждый раз, когда мы обращались к столбцам ? Чтобы избежать каждого запроса на копирование-вставку функции, я мог бы по-прежнему работать с представлением или хранимой процедурой, но дублирование данных во избежание неправильного пересчета звучит неправильно.

Решения, которые я вижу (наверное, я предпочитаю 2.2.1) 

1. Physically duplicate columns
1.1 In the same table
1.1.1 Added by each script that does a modification (INSERT/UPDATE/REPLACE/...)
1.1.2 Maintained by a trigger on each modification
1.2 In a separate table
1.2.1 Added by each script that does a modification (INSERT/UPDATE/REPLACE/...)
1.2.2 Maintained by a trigger on each modification
2. On-demand transformation
2.1 Each query has to perform the transformation
2.1.1 Using copy-paste in the source code
2.1.2 Using a library
2.1.3 Using a STORED PROCEDURE
2.2 A view performs the transformation 
2.2.1 A separate table replacing the entire table
2.2.2 A separate table just adding the date-fields for the primary keys

Правильно ли я сказал, что лучше пересчитать, чем хранить ? И будет ли view хорошим решением?

1 Ответ

1 голос
/ 01 июня 2010

Я был проверял это все утро. Я дублировал таблицу 2 раза:

  • один раз за использование вида, который превращает поле VARCHAR в Поле DATE для каждого запроса, используя STR_TO_DATE
  • один раз для добавления столбца и выполнения ОБНОВЛЕНИЯ с использованием STR_TO_DATE

После этого я потерял много разных запросов - представление выполняется немного медленнее , как и ожидалось, но только на десятки миллисекунд.

Поскольку для хранения дополнительного столбца у меня уходит дополнительно 7 МБ (и это влияет на использование диска и ОЗУ), и наш сервер имеет запасную мощность ЦП, но не ОЗУ / IO, Я склоняется к «преобразовать CHAR в DATE для каждого запроса» .

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

...