MySQL: есть ли что-то вроде внутреннего идентификатора записи для каждой записи в таблице MySQL?

Я создаю приложение для работы с электронными таблицами, используя MySQL в качестве хранилища, мне нужно определить записи, которые обновляются на стороне клиента, чтобы сохранить изменения.

Есть ли способ, такой как какой-то «внутренний идентификатор записи» (внутренний, используемый самим механизмом базы данных), для уникальной идентификации записей, чтобы я мог обновить правильный?

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

ВАЖНО: приложение для работы с электронными таблицами предназначено для работы с ЛЮБОЙ таблицей, даже с чрезвычайно плохо спроектированной, без каких-либо ключей, поэтому такие решения, как «определить поле с УНИКАЛЬНЫМ индексом и работать с ним», не подходят, структура таблицы может быть чрезвычайно изменчивой. и не должно иметь значения.

Большое спасибо.


mysql identifier record
person Webmaster    schedule 13.02.2010    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Насколько мне известно, такого уникального внутреннего идентификатора (скажем, простого идентификатора строки) не существует.

Вы можете возможно запустить SELECT без какой-либо сортировки, а затем получить n-ю строку, используя LIMIT. При каких условиях он надежен и безопасен в использовании, гуру mySQL должен подтвердить. Наверное, никогда.

Попробуйте поиграться с phpMyAdmin, веб-интерфейсом для mySQL. Он предназначен для работы с плохо спроектированными таблицами без ключей. Если я правильно помню, он использует все столбцы, которые может получить в таких случаях:

UPDATE xyz set a = b WHERE 'fieldname'  = 'value' 
                       AND 'fieldname2' = 'value2' 
                       AND 'fieldname3' = 'value3' 
                       LIMIT 0,1;

и так далее.

Конечно, это не совсем безопасно для дубликатов.

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

person Pekka    schedule 13.02.2010
comment
Я полагаю, что phpMyAdmin также добавит LIMIT 1 к предложениям DELETE и UPDATE, если первичный ключ недоступен. - person Annika Backstrom; 13.02.2010
comment
@ Адам Правда. Я добавил его в пример. Вероятно, это безопасно, пока phpMyAdmin является единственным экземпляром, имеющим доступ к базе данных. - person Pekka; 13.02.2010
comment
Ваше здоровье. Это именно то решение, которое я использую в данный момент, и оно определенно далеко от дублирования. Вау, я почувствовал мурашки по коже. Последнее на самом деле блестящая идея, действительно вызывающая мурашки по коже, но даже если бы я взялся за эту миссию, я не мог бы изменить структуру таблицы. Это должно быть воспроизведено в совершенно новой временной таблице. Спасибо. - person Webmaster; 13.02.2010

arrow_upward
0
arrow_downward

MySQL имеет числовые столбцы с автоматическим увеличением, которые вы можете добавить и даже определить как первичный ключ, что даст вам уникальный идентификатор записи, автоматически сгенерированный базой данных. Вы можете запросить идентификатор последней записи, которую вы только что вставили, с помощью select LAST_INSERT_ID()

пример из официальной документации mysql здесь

person ggiroux    schedule 13.02.2010
comment
Неплохая идея, не соответствует спецификациям: нет контроля над структурой таблицы, нельзя добавлять поля, ключи. - person Webmaster; 13.02.2010

arrow_upward
0
arrow_downward

Насколько мне известно, в MySQL отсутствует неявная функция ROWID, как в Oracle (и существует в других движках с собственным синтаксисом). Вам нужно будет создать собственное поле AUTO_INCREMENT.

person Annika Backstrom    schedule 13.02.2010
comment
Не соответствует спецификации: нет контроля над структурой таблицы, нельзя добавлять поля, ключи. Упомянутая вами функция ROWID, вероятно, и есть то, о чем я пытаюсь рассказать. Спасибо. - person Webmaster; 13.02.2010