Если вы хотите сделать свою базу данных масштабируемой, лучшим подходом будет добавление нового столбца LATESTDATE
вместе с триггером вставки/обновления, который устанавливает для него последнее из двух полей-кандидатов, используя, например, самый лучший.
Выполнение построчных функций для ваших выборок очень быстро замедляется по мере того, как таблица становится больше. Если вы хотите, чтобы производительность оставалась приемлемой по мере роста таблицы, этот трюк является распространенным.
Технически это нарушает 3NF, поскольку дублирует одну из дат, но нарушение допустимо по соображениям производительности, и вы по-прежнему поддерживаете свойства ACID, поскольку триггеры требуют, чтобы столбцы оставались согласованными.
Я не знаю синтаксиса триггера MySQL, но я бы сделал что-то вроде:
- Создайте новый столбец, установив для него подходящее значение по умолчанию.
- Создайте триггеры вставки/обновления, чтобы обеспечить отражение изменений.
- Коснитесь всех строк с запросом типа
update TBL set ADDDATE = ADDDATE
, чтобы триггер срабатывал для всех текущих строк.
Преимущество этого решения заключается в том, что оно переносит стоимость вычислений на время изменения данных, а не каждый раз, когда вы запрашиваете базу данных. Это амортизирует затраты на все чтения, делая их более эффективными (если только вы не один из тех очень редких зверей, у которых таблица записывается чаще, чем читается).
Имейте в виду, что в этом может не быть необходимости, если размер вашей таблицы относительно небольшой — я работаю в средах, где таблицы действительно огромны.
person
paxdiablo
schedule
16.07.2010