| Вопрос: Получение значения автоинкримента | Добавлено: 24.10.05 16:35 |
Автор вопроса:  piton | ICQ: 315928410 |
|
Такая проблема:
Имеется таблица, в ней один из столбцов(ID) имеет автоинкремент, т.е. значение заполняется автоматически целым числом. При добавлении новой записи ей присаивается новое значение ID. Как можно узнать значение этого ID, при том что с базой одновременно могут работать несколько человек и соответственно может идти добавление одновременно нескольких записей, т.е. как узнать ID записи которую добавил именно я |
| Ответы | Всего ответов: 25 |
|
Номер ответа: 1 Автор ответа:  AndreyMp ICQ: 237822510 Вопросов: 28 Ответов: 1182 |
Профиль | | #1 | Добавлено: 24.10.05 17:45 |
| Вероятно должно быть поле в базе, которое идентифицирует юзера произведшего добавление (изменение) записи - логин,IP-компа, что угодно уникальное для конкретного человека. | ||
|
Номер ответа: 2 Автор ответа: GSergВопросов: 0 Ответов: 1876 
|
Профиль | | #2 | Добавлено: 24.10.05 18:23 |
|
А никак.
Нет, есть конечно SELECT @@IDENTITY, но... Вообще, в нормальной базе никогда не бывает нужно узнавать счётчик. Он там только для внутреннего пользования. А если на него завязана логика приложения, тем хуже... |
||
|
Номер ответа: 3 Автор ответа: ПавелАдминистратор ICQ: 326066673 Вопросов: 368 Ответов: 5968 |
Web-сайт: Профиль | | #3 | Добавлено: 24.10.05 18:29 |
|
ИМХО знание Primary Key всегда в хозяйстве пригодится. Хотя бы, чтобы
проинициализировать поле ID только что сохраненного в базе объекта. То есть создан объект, сохраняется в базе, сразу в свойство ID пишется назначенный ему СУБД ID, и объект становится вполне юзабельным внтутри слоя бизнес-логики. А без ID его ни обновить ни удалить. Как предлагаешь поступать иначе? |
||
|
Номер ответа: 4 Автор ответа: GSergВопросов: 0 Ответов: 1876
|
Профиль | | #4 | Добавлено: 24.10.05 20:13 |
|
Понимаешь, любое автоматически создаваемое число (когда всё правильно спроектировано... хотя я и сам иногда, признаться...) вообще не должно попадаться на глаза пользователю в частности и участвовать в бизнес-логике вообще...
Если у чего-то есть ID, который предназначен для пользователя, то этот ID должен быть, соответственно, читаемой строкой (например, вольной аббревиатурой названия компании) и задаваться должен самим же пользователем. Если у чего-то есть ID, который по идее подходит под IDENTITY (например, номер договора), то следует избежать соблазна и завести отдельно два поля - первичный ключ и номер договора. В общем, всё это должно оставаться внутри базы и обеспечивать её функциональность и целостность, но никак не бизнес-логику и диалог с пользователем. ИМХО. |
||
|
Номер ответа: 5 Автор ответа: ПавелАдминистратор ICQ: 326066673 Вопросов: 368 Ответов: 5968 |
Web-сайт: Профиль | | #5 | Добавлено: 24.10.05 20:25 |
|
Это безусловно, ID пользователю не нужен. Но и бизнес-логику пользователь как правило не видит, он лишь слой представления (будь то GUI или веб-сайт) видит.
А ID целесообразно все же использовать в бизнес-логике. Хотя бы для однозначной идентификации объекта. Нужно изменить Email пользователя (пользователь представлен классом User, у него свойство Email). Dim MyUser As User
MyUser.Email = "vasya@pupkin.ru" MyUser.Save() ' либо UsersMapper.Update(MyUser) Как в методе Save узнать, какую именно строку БД нужно обновить? Только по ID. Самый явный и быстрый (учитывая, что ID - Primary Key) способ. Так же для идентификации объектов в кеше. Да даже если выводишь пользователю форму редактирования объекта, надо же запомнить где-то, что за объект он реактирует - прописать в ViewState (если юзается ASP .NET) значение поля ID и нет проблем. Я не прав? |
||
|
Номер ответа: 6 Автор ответа: ПавелАдминистратор ICQ: 326066673 Вопросов: 368 Ответов: 5968 |
Web-сайт: Профиль | | #6 | Добавлено: 24.10.05 20:26 |
| Да, по теме... Народ почему-то рекомендует пользоваться SCOPE_IDENTITY вместо @@IDENTITY. Мотивацию данного выбора уже не помню, читал где-то в блогах на Gotdotnet. | ||
|
Номер ответа: 7 Автор ответа: ПавелАдминистратор ICQ: 326066673 Вопросов: 368 Ответов: 5968 |
Web-сайт: Профиль | | #7 | Добавлено: 24.10.05 20:28 |
|
Ох, нафлудил же я второпях... Чтоб недопониманий не было, поправлю код
Dim MyUser As User
'Некоторые действия, в процессе которых инициализруется MyUser 'Возвожно нечто вроде MyUser = UsersMapper.GetByID(CType(ViewState("EditedUserID"  , Int32))
MyUser.Email = "vasya@pupkin.ru" MyUser.Save() ' либо UsersMapper.Update(MyUser) |
||
|
Номер ответа: 8 Автор ответа: GSergВопросов: 0 Ответов: 1876
|
Профиль | | #8 | Добавлено: 24.10.05 22:39 |
|
Я не прав?
Может быть да, может быть нет 
Как-то один человек, чьи знания баз данных мне представляются весьма и весьма обширными, сказал: "Если ты завязываешь логику на первичный ключ, ты сам себе злобный буратино" (не буквально, но почти). Сейчас вот смотрю в недра одного бизнес-приложения, написанного в UK и работающего на SQL Server 2000. 270 таблиц, в каждой таблице первичный ключ, и в каждой таблице он не используется иначе как первичный ключ. Никакой связи с бизнес логикой вообще, хотя могли бы... Нет, я не к тому, что именно так всегда хорошо и правильно. Но почему-то у меня такое представление складывается, и чем дальше, тем как-то оно усиливается
|
||
|
Номер ответа: 9 Автор ответа: EROSВопросов: 58 Ответов: 4255  |
Профиль | | #9 | Добавлено: 25.10.05 00:48 |
|
и в каждой таблице он не используется иначе как первичный ключ. Никакой связи с бизнес логикой вообще
Хм... а как еще можно использовать первичный ключ КРОМЕ как первичный ключ?? И КАК можно создать бизнес-логику БЕЗ использования первичного ключа?? Будь то хоть автоинкрементное поле, либо поле заполняемое юзером.. В любом случае,без использования уникального поля бизнес-логики не построить. В виду отсутствия возможности однозначной идентификации записи.. ИМХО.. И как быть в таком случае с построением связей,отношений и зависимостей таблиц?? Если не это называется бизнес-логикой,то что????????? |
||
|
Номер ответа: 10 Автор ответа: EROSВопросов: 58 Ответов: 4255 |
Профиль | | #10 | Добавлено: 25.10.05 01:05 |
|
А что касается вопроса топика,то не понятно, о какой БД в целом идет речь. Если это SQL,то уже ответили, если же это mdb,то могу предложить следующий вариант решения. Хотя,как мне кажется, этот вариант будет работать на любой БД, так как значение автоинкремента присваивается в момент добавления новой строки..
With NewRow
.Edit !Field1="Вася" !Field2="Пупкин" RetVal=!ID .Update End with И в переменной RetVal будет содержаться нужное тебе значение. |
||
|
Номер ответа: 11 Автор ответа: GSergВопросов: 0 Ответов: 1876
|
Профиль | | #11 | Добавлено: 25.10.05 02:31 |
| Которое будет равно нулю. Ибо рано. | ||
|
Номер ответа: 12 Автор ответа: EROSВопросов: 58 Ответов: 4255 |
Профиль | | #12 | Добавлено: 25.10.05 08:55 |
| GSerg, ошибаешься. Все работает,причем великолепно! | ||
|
Номер ответа: 13 Автор ответа: ПавелАдминистратор ICQ: 326066673 Вопросов: 368 Ответов: 5968 |
Web-сайт: Профиль | | #13 | Добавлено: 25.10.05 11:21 |
| Тогда как иначе можно решить задачу однозначного сопоставления записи в БД и объекта бизнес-логики? | ||
|
Номер ответа: 14 Автор ответа: EROSВопросов: 58 Ответов: 4255 |
Профиль | | #14 | Добавлено: 25.10.05 12:10 |
| Паш, а никак ты её не решишь!!Без уникального поля-никак!! Можно,конечно задействовать составные индексы по нескольким полям БЕЗ использования первичного ключа.. Но это,мягко говоря, через задницу.. )) | ||
|
Номер ответа: 15 Автор ответа: GSergВопросов: 0 Ответов: 1876
|
Профиль | | #15 | Добавлено: 25.10.05 12:20 |
|
GSerg, ошибаешься. Все работает,причем великолепно!
Попробуй через ADO. Попробуй также при клиентском курсоре. И тип своей базы скажи ещё? Можно,конечно задействовать составные индексы по нескольким полям БЕЗ использования первичного ключа..
По двум постам ув. тов. EROSа могу предположить, что он сделал вывод, будто я призываю отказаться от первичного ключа, что в корне неверно. Тогда как иначе можно решить задачу однозначного сопоставления записи в БД и объекта бизнес-логики?
Хм... Давай на примере
Приведи пример, когда, по твоему мнению, необходимо выполнить это сопоставление. Будем разбирать
|
||