Вставка уникального максимального значения в поле VARCHAR

[Аlex]

Вставка уникального максимального значения в поле VARCHAR

Помогите составить структуру таблиц.
Должна быть таблица, одно из полей которой имеет тип VARCHAR и представляет собой некие ключи для текстов, причём заполняться оно может как автоматически (при добавлении сообщения через веб-форму), так и вручную (человеком при написании модуля).
Если поле заполняется человеком, ключи представляют собой некие фразы типа SOME_KEY. Если заполняет программа, проще всего, по-видимому, генерировать ключи в виде числовой последовательности 1, 2, 3 и т.п. Либо SOME_KEY1, SOME_KEY2 - не суть важно.

При этом возникает проблема - где каждый раз брать последнее из этих самых чисел? Делать SELECT, а потом INSERT нельзя - между этими двумя операциями кто-то может начать делать то же самое, и база нарушится. Один из вариантов такой - дополнительная таблица с полем auto_increment, которое заполняется перед каждой операцией по добавлению нового ключа, а сам номер ключа берется из mysql_insert_id()

Но это с двумя таблицами. А можно ли обойтись одним запросом? Например:

INSERT INTO table1 (keyword, text) VALUES (MAX(keyword AS INT)+1, 'text');

Понятно, что работать это не будет, но, надеюсь, мысль понятна - можно ли составить подобный запрос, чтобы обойтись всё-таки одной таблицей?

 

[!diss]

Re: Вставка уникального максимального значения в поле VARCHAR

Автор оригинала: Аlex
Но это с двумя таблицами. А можно ли обойтись одним запросом? Например:

INSERT INTO table1 (keyword, text) VALUES (MAX(keyword AS INT)+1, 'text');

Понятно, что работать это не будет, но, надеюсь, мысль понятна - можно ли составить подобный запрос, чтобы обойтись всё-таки одной таблицей?

А почему не

INSERT INTO table1 (keyword, text) VALUES (MD5('text'), 'text');

 

[Аlex]

Дело в том, что речь идёт о языковой поддержке. Текст может храниться в базе на нескольких языках. При этом разработчик модуля "News" будет в самом модуле писать не текст, а ключи, например, NEWS_HEADER, NEWS_TEXT, NEWS_AUTHOR, текст же будет заполняться в базе при установке модуля и может дополняться переводами ан другие языки в любой момент. Заставлять разработчков что-то вычислять для каждой фразы несколько неэтично, да и для каждого языка MD5 будет, естесственно, разный, так что ключи - самый простой вариант в данном случае.

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

-~{}~ 03.03.06 08:35:

Нечто очень похожее на то, что нужно, получилось при использовании @@IDENTITY:
INSERT INTO table1 (keyword, text) VALUES (@@IDENTITY+1, 'text');
Но @@IDENTITY обнуляется с каждой новой сессией, так что тоже не подходит.

 

[!diss]

Автор оригинала: Аlex Нечто очень похожее на то, что нужно, получилось при использовании @@IDENTITY:
INSERT INTO table1 (keyword, text) VALUES (@@IDENTITY+1, 'text');
Но @@IDENTITY обнуляется с каждой новой сессией, так что тоже не подходит.

Извините, а AUTO_INCRЕMENT вам не подходит?
или что-то типа INSERT INTO table1 (keyword, text) VALUES ('NEWS_'+NOW(), 'text');

 

[Аlex]

AUTO_INCRЕMENT бы подошёл, если бы mysql позволяла присваивать это свойство полю VARCHAR. Вставляем в это поле текст - оно работает как обычный VARCHAR, пропускаем - mysql заполняет его последовательно числами.

Насчёт 'NEWS_'+NOW() - хорошая идея. Только является ли она более красивой, чем дополнительная таблица?

-~{}~ 03.03.06 10:03:

В общем, пришёл к такому решению:
system_keyword (INT AUTO_INCREMENT)
user_keyword (VARCHAR)
...
text (TEXT)

При заполнении таблицы если есть user_keyword, он вставляется, если нет, поле оставляется пустым. id растёт всегда.

А "вынимается" это всё запросом:
SELECT * FROM table1 WHERE user_keyword='$keyword' OR system_keyword='$keyword';

Позволит обойтись одной таблицей и упорядоченными числами. Но если кто придумает более практичное решение, буду благодарен.

 

[chira]

Аlex

убери user_keyword и используй только system_keyword

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

измени вектор своих усилий ...
скорректируй свой алгоритм, что-бы использовать MySQL

тогда работа с базой не будет для тебя проблемной частью.

 

[Аlex]

user_keyword я не могу убрать по той простой причине, что VARCHAR не может иметь свойства auto_increment, читайте внимательней.

 

[Фанат]

господи, а составить СЛОВАРЬ соответствий цифровых индексов этим бессмысленным NEWS_HEADER, NEWS_TEXT тебе никак идея в голову не приходит?
и хранить таки ЧТО-ТО ОДНО?

 

[Аlex]

И кто будет его составлять? Разработчик модуля, который понятия не имеет о текущем состоянии счётчика, или система, которой придётся парсить новые модули на наличие шаблонов и подобных переменных?

Чем, собственно, мой вариант плох?

 

[Фанат]

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

 

[Аlex]

Объяснили что? Пока было лишь несколько предложений, на каждое из которых я ответил, почему они не подходят.
Вариантов решений я сам могу сам напридумывать хоть несколько десятков, и общим у них у всех будет то, что они не подходят под мой конкретный случай. Почему нельзя использовать твой словарь, тебе тоже объяснили.

>> зачем ты ждёшь помощи от людей, которые не видят смысла в твоих действиях
Не нужно ничего придумывать, от таких людей я помощи не жду. Если кто-то в состоянии понять проблему и дать ценный совет - буду очень признателен.

-~{}~ 06.03.06 11:57:

В принципе, как уже сказано, проблема решена. На мой взгляд, довольно удачно.
Но если кто объяснит, чем такое решение плохо, или предложит более красивое, также буду благодарен.