Вопрос наилучшей практики для MySQL: заказ по идентификатору или дате? - PullRequest
Новая
       3

Вопрос наилучшей практики для MySQL: заказ по идентификатору или дате?

10 голосов
/ 30 января 2010

Это своего рода нубистский вопрос, но на этот вопрос мне никогда не давали прямого ответа.

Предположим, у меня есть таблица БД со следующими полями и значениями: 

| 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 ]

9 голосов
/ 30 января 2010

Если равно , то есть вероятность, что вы добавите два с одной и той же датой, вам, вероятно, потребуется: 

SELECT balance FROM my_table ORDER BY date_added DESC,id DESC LIMIT 1;

(обратите внимание на «нисходящее» предложение в обоих полях).

Тем не менее, вам нужно будет принять во внимание то, что вы хотите, чтобы произошло, когда кто-то добавляет корректирующую запись от 2 nd февраля, которой присваивается дата 31 st января убедитесь, что январь завершен. У него будет ID больше, чем у 1 ст февраля.

Как правило, системы учета просто работают на дату. Возможно, если бы вы сказали нам , почему порядок важен, мы могли бы сделать другие предложения.

В ответ на ваш комментарий:

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

Я бы дал несколько советов - это все, о чем я мог подумать сразу, я обычно излагал гораздо больше «советов» с еще меньшим воодушевлением :-) Первые два, больше связанные с базой данных, чем связанные с бухгалтерским учетом, являются:

Во-первых, сделайте все в третьей нормальной форме и вернитесь, только если у вас есть проблемы с производительностью. Это избавит вас от лишних хлопот с дублирующимися данными, которые могут выйти из строя. Даже если вы вернетесь, используйте триггеры и другие возможности СУБД, чтобы гарантировать, что данные не выходят из строя.

Например, если вы хотите ускорить поиск по столбцу last_name, вы можете создать столбец upper_last_name (проиндексированный), а затем использовать его для поиска записей, соответствующих вашему поисковому термину в верхнем регистре. Это почти всегда будет быстрее, чем функция для каждой строки upper(last_name). Вы можете использовать триггер вставки / обновления, чтобы гарантировать, что upper_last_name всегда задан правильно, и это требует затрат только при изменении имени, а не при каждом поиске.

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

В-третьих (и это больше связано с учетом), вам обычно не нужно беспокоиться о количестве транзакций при расчете сальдо на лету. Это связано с тем, что системы учета обычно имеют функцию пролонгации на конец года, которая сбрасывает начальные сальдо.

Так что обычно вам никогда не приходится обрабатывать данные более чем за год, которые, если вы не являетесь правительством США или Microsoft, не так уж обременительны.

3 голосов
/ 30 января 2010

Возможно быстрее по идентификатору, но безопаснее по дате и времени; используйте последний, если есть проблемы с производительностью, добавьте индекс.

2 голосов
/ 30 января 2010

Лично я бы никогда так не доверял автоинкременту. Я бы отсортировал по дате.

Я почти уверен, что идентификатор гарантированно будет уникальным, но не обязательно последовательным и увеличивающимся.

...