Есть таблица в которой храняться юзеры, у каждого свой идентификатор, как добавить нового пользователя так чтобы идентификатор был уникальным, но при этом и не вытаскивать из БД всех остальных, чтобы узнать их номера.
Меня интересует общепризнанная практика.
Здравствуйте, _Lito, Вы писали:
_L>Есть таблица в которой храняться юзеры, у каждого свой идентификатор, как добавить нового пользователя так чтобы идентификатор был уникальным, но при этом и не вытаскивать из БД всех остальных, чтобы узнать их номера. _L>Меня интересует общепризнанная практика.
Бери в качестве идентификатора GUID!
Новый GUID можно так получить, не прочитывая БД:
Пример на VB.NET для использованмя в SQL-String:
Dim g As String = System.Guid.NewGuid().ToString("D")
_L>Есть таблица в которой храняться юзеры, у каждого свой идентификатор, как добавить нового пользователя так чтобы идентификатор был уникальным, но при этом и не вытаскивать из БД всех остальных, чтобы узнать их номера.
Здравствуйте, _Lito, Вы писали:
_L>Есть таблица в которой храняться юзеры, у каждого свой идентификатор, как добавить нового пользователя так чтобы идентификатор был уникальным, но при этом и не вытаскивать из БД всех остальных, чтобы узнать их номера. _L>Меня интересует общепризнанная практика.
Для этого есть sequence. Или auto_increment в mysql.
Если надо не зависить от БД, то завести маленькую табличку, куда писать последний использованный номер. Только в этом случае надо позаботиться о синхронизации.
PF>Бери в качестве идентификатора GUID!
PF>Новый GUID можно так получить, не прочитывая БД:
Взять в качестве id GUID очень хороший способ.
Единственно, не все базы данных поддерживают тип GUID и соответсвенно будут правильно индексировать по этому полю. В этом случае придется все же воспользоваться каунтером и получать id после инсерта.
А я тут нашел,что полю можно присвоить свойство identity, тогда СУБД сама выполняет контроль уникальности этого поля и не дает его менять.
Теперь с добавлением проблем нет, но вот мне надо добавить в другую таблицу данные использующие этот новый идентификатор, который СУБД создала сама.
Как можно быстрее всего его получить или надо новый SELECT запрос делать.
Здравствуйте, _Lito, Вы писали:
_L>А я тут нашел,что полю можно присвоить свойство identity, тогда СУБД сама выполняет контроль уникальности этого поля и не дает его менять. _L>Теперь с добавлением проблем нет, но вот мне надо добавить в другую таблицу данные использующие этот новый идентификатор, который СУБД создала сама. _L>Как можно быстрее всего его получить или надо новый SELECT запрос делать.
В поиск. Это вопрос каждые пару дней задают... Ищи лучше в db
Здравствуйте, _Lito, Вы писали:
_L>А я тут нашел,что полю можно присвоить свойство identity, тогда СУБД сама выполняет контроль уникальности этого поля и не дает его менять. _L>Теперь с добавлением проблем нет, но вот мне надо добавить в другую таблицу данные использующие этот новый идентификатор, который СУБД создала сама. _L>Как можно быстрее всего его получить или надо новый SELECT запрос делать.
Здравствуйте, fist, Вы писали:
F>Здравствуйте, Peter Fleischer, Вы писали:
PF>>Бери в качестве идентификатора GUID!
PF>>Новый GUID можно так получить, не прочитывая БД:
F>Взять в качестве id GUID очень хороший способ. F>Единственно, не все базы данных поддерживают тип GUID и соответсвенно будут правильно индексировать по этому полю. В этом случае придется все же воспользоваться каунтером и получать id после инсерта.
Почему должен подерживать GUID еси ипсолзовать String (см. мой пример)? Не все БД поддерживают каунтер (напр. Jet + dBase)
PF>Почему должен подерживать GUID еси ипсолзовать String (см. мой пример)? Не все БД поддерживают каунтер (напр. Jet + dBase)
Я просто имел ввиду, что использовать GUID в качестве id без веских причин не очень хорошо. А уж тем более хранить его как строку, то есть для одного id будет использоваться 32 байта в строковом представлении, очень необдуманный шаг, результатом которого будут потери в скорости.
Хотя я не отрицаю, что использовать GUID для решения задач репликации и ряда вопросов связанных с проектированием распределенных баз данных просто необходимо.
