Сохранения последнего значения кастомной автонумерации

Ситуация такая: нужно создать кастомную автонумерацию, причем номер придается не при создании записи, а в какой-то момент ее жизненного цикла через тригер.

Автономер содержит неизменную часть, +часть содержащую дату, + собственного автонумерацию (возрастающие числа), которая должна быть уникальна только в пределах одного дня.

Вопрос: как сохранить последнее значение автонумерции?

Мой вариант: создать Кастом Сеттинг в котором только два поля (дата и значение) и только одна запись.

При создании нового кастомного автономера - брать эту запись Кастомного сетинга, проверять дату в первом поле, если не сегодня - то начать отсчет с единицы, если сегодня - то взять значение из второго поля, увеличить на единицу, созданный автономер закинуть в поле Рабочей записи, и в той единственной записи каст сетинга записать текущую дату и только что созданный автономер (его инкриментируемую часть).

Ваше мнение?

Den Brown

Ситуация такая: нужно создать кастомную автонумерацию, причем номер придается не при создании записи, а в какой-то момент ее жизненного цикла через тригер.

Автономер содержит неизменную часть, +часть содержащую дату, + собственного автонумерацию (возрастающие числа), которая должна быть уникальна только в пределах одного дня.

Вопрос: как сохранить последнее значение автонумерции? 

Мой вариант: создать Кастом Сеттинг в котором только два поля (дата и значение) и только одна запись.
При создании нового кастомного автономера - брать эту запись Кастомного сетинга, проверять дату в первом поле, если не сегодня - то начать отсчет с единицы, если сегодня - то взять значение из второго поля, увеличить на единицу, созданный автономер закинуть в поле Рабочей записи, и в той единственной записи каст сетинга записать текущую дату и только что созданный автономер (его инкриментируемую часть).

Ваше мнение?

Я бы не заморачивался с custom settings.
1. Последнюю созданную запись можно получить по ORDER BY CreatedDate DESC LIMIT 1
2. Достаешь из нее предудущее значение - парсишь (получаешь дату и day number)
3. Сравниваешь дату с TODAY() и если не равно начинаешь с единицы или продолжаешь.
Логика не сложная, если шаг 2 не вызывает проблем.

Этот вариант исключает промежуточное хранение данных. Оно мне кажется лишним.

Dmitry Shnyrev

Я бы не заморачивался с custom settings. 
1. Последнюю созданную запись можно получить по ORDER BY CreatedDate DESC LIMIT 1
2. Достаешь из нее предудущее значение - парсишь (получаешь дату и day number)
3. Сравниваешь дату с TODAY() и если не равно начинаешь с единицы или продолжаешь.
Логика не сложная, если шаг 2 не вызывает проблем.

Этот вариант исключает промежуточное хранение данных. Оно мне кажется лишним.

Dmitry Shnyrev

Я бы не заморачивался с custom settings.
1. Последнюю созданную запись можно получить по ORDER BY CreatedDate DESC LIMIT 1
2. Достаешь из нее предудущее значение - парсишь (получаешь дату и day number)
3. Сравниваешь дату с TODAY() и если не равно начинаешь с единицы или продолжаешь.
Логика не сложная, если шаг 2 не вызывает проблем.
Этот вариант исключает промежуточное хранение данных. Оно мне кажется лишним.

Вариант не плохой, но проблема с уникальностью значения. Например если создать набор записей, в последнем храниться наибольший номер, удаляем последний. Следующий элемент опять будет содержать номер как и предыдущий (удалённый). Если это не критично для бизнес модели, тогда вариант Дмитрия наилучший.

Dmitry Lisovsky

[quote="Dmitry Shnyrev"]Я бы не заморачивался с custom settings. 
1. Последнюю созданную запись можно получить по ORDER BY CreatedDate DESC LIMIT 1
2. Достаешь из нее предудущее значение - парсишь (получаешь дату и day number)
3. Сравниваешь дату с TODAY() и если не равно начинаешь с единицы или продолжаешь.
Логика не сложная, если шаг 2 не вызывает проблем.

Этот вариант исключает промежуточное хранение данных. Оно мне кажется лишним.[/quote]

Вариант не плохой, но проблема с уникальностью значения. Например если создать набор записей, в последнем храниться наибольший номер, удаляем последний. Следующий элемент опять будет содержать номер как и предыдущий (удалённый). Если это не критично для бизнес модели, тогда вариант Дмитрия наилучший.

Вариант Дмитрия не подошел, так как этот номер придается не в момент создания записи, а когда-то позже, и словить ту запись, в которой стоит "последний" номер - не получается.

Кроме того - действительно - уникальность.

Все решилось проще. Задание изменили -вот этого нет: возрастающее число, которое должна быть уникально только в пределах одного дня.

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

Den Brown

Вариант Дмитрия не подошел, так как этот номер придается не в момент создания записи, а когда-то позже, и словить ту запись, в которой стоит "последний" номер - не получается.

Кроме того - действительно - уникальность.

Все решилось проще. Задание изменили -вот этого нет: [i]возрастающее число, которое должна быть уникально только в пределах одного дня.[/i]

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