Вопрос о лучшей практике для MySQL: порядок идентификатором или датой?
Это - своего рода noobish вопрос, но это - то, на котором мне никогда не давали прямой ответ.
Предположим, что у меня есть Таблица базы данных со следующими полями и значениями:
| id | date_added | balance |
+------------------------------------+
| 1 | 2009-12-01 19:43:22 | 1237.50 |
| 2 | 2010-01-12 03:19:54 | 473.00 |
| 3 | 2010-01-12 03:19:54 | 2131.20 |
| 4 | 2010-01-20 11:27:31 | 3238.10 |
| 5 | 2010-01-25 22:52:07 | 569.40 |
+------------------------------------+
Это для очень простой 'бухгалтерской' подсистемы. Я хочу получить новый баланс. id поле установлено на auto_increment. Как правило, я использовал бы:
SELECT balance FROM my_table ORDER BY date_added DESC LIMIT 1;
Но я должен сделать абсолютно уверенным, что возвращенное значение ново... (см. id# 2 и 3 выше),
1) Был бы я быть более обеспеченным использованием:
SELECT balance FROM my_table ORDER BY id DESC LIMIT 1;
2) Или это было бы лучшим решением?:
SELECT balance FROM my_table ORDER BY date_added,id DESC LIMIT 1;
AFAIK, auto_increment работы вполне прилично, но действительно ли это достаточно надежно для сортировки чего-то это крайне важное? Вот почему я думаю, сортируя по обоим полям, лучшая идея, но я видел некоторое действительно изворотливое поведение в MySQL, когда я сделал это в прошлом. Или если бы существует еще лучшее решение, я ценил бы Ваш вход.
Заранее спасибо!
Brian
3 ответа
Если там это шанс, который вы получите два добавленных в той же дате, вам, вероятно, понадобится:
SELECT balance FROM my_table ORDER BY date_added DESC,id DESC LIMIT 1;
(обратите внимание на «нисходящее» предложение на обоих полях).
Однако вам нужно будет принять во внимание то, что вы хотите произойти, когда кто-то добавляет регулировочную запись 2 ND в феврале, который дается дата 31 ST Убедитесь, что январь месяц завершен. Он будет иметь удостоверение личности больше, чем те, которые сделаны на 1 ST февраля.
Как правило, системы бухгалтерского учета просто работают на дату. Возможно, если бы вы могли сказать нам Почему Важно Орден, мы могли бы сделать другие предложения.
В ответ на ваш комментарий:
Я хотел бы услышать любые другие идеи или совет, которые вы могли бы иметь, даже если они не имеют темы, так как у меня нулевые знания моделей баз данных в типе бухгалтерского учета.
Я бы предоставил несколько советов - это все, что я мог сразу думать, я обычно провожу гораздо больше «совета» с еще менее поощрением :-) Первые две, более, связанные с базой данных, чем бухгалтерский Есть:
Во-первых, делайте все в третьей нормальной форме и возвращаются только тогда, если и когда у вас проблемы с производительностью. Это сэкономит вам много англ с дублирующимися данными, которые могут выйти из шага. Даже если вы вернетесь, используйте триггеры и другие возможности СУБД, чтобы гарантировать, что данные не выходят из шага.
Пример, если вы хотите ускорить поиск в столбце LAST_NAME, вы можете создать столбец oper_last_name (индексированный), а затем используйте это, чтобы найти записи, сопоставив свой поисковый запрос в верхнем направлении. Это почти всегда будет быстрее, чем функция подряд Верхний (last_name) . Вы можете использовать триггер вставки / обновления, чтобы убедиться, что Explay_last_name всегда устанавливается правильно, и это вставляет затраты только тогда, когда имени меняется, не каждый раз, когда вы ищете.
Во-вторых, не дублируйте данные даже через таблицы (например, ваша текущая схема), если вы не можете использовать те же трюки Tryger-Type, чтобы гарантировать, что данные не выйдут из шага. Что будет делать ваш клиент, когда вы отправляете им счет, где окончательный баланс не соответствует исходным балансам плюс покупки? Это не собирается сделать вашу компанию очень профессионально: -)
В-третьих (и это больше связано с учетом), вам вообще не нужно беспокоиться о количестве транзакций при расчете остатков на лету. Это связано с тем, что системы бухгалтерского учета обычно имеют функцию Roll-Over на конец года, которая сбрасывает открывающие балансы.
Итак, вы обычно никогда не должны обрабатывать более годовых данных, одновременно, если вы, если вы не являетесь правительством США или Microsoft, не то, что обременительно.
Может быть, быстрее по ID, но безопаснее по DateTime; Используйте последние, если есть проблемы с производительностью, добавьте индекс.
Лично я бы никогда не доверял автореценции таким образом. Я бы сортировал по дате.
Я почти уверен, что идентификатор гарантированно будет уникальным, но не обязательно последовательным и возрастающим.