Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

автокрименентное значение [D7, MySQL]

Страницы: 1 2 3 >
{Alex} © (2006-04-05 16:51:00)
маленький такой вопросик:

Можно как нибуть получить автокрименентное значение поля,
т.е. значение которое бдет присвоено следующей записи, перед ее добавление в таблицу.

Используется MySQL&MDAC&Delphi

Курдль (2006-04-07 10:13:00) [1]

> Это наверное когда в коде присутствуют ссылки на конкретные
> ID-шники?

Бывает, конечно, такой соблазн. Типа "субъект с ID=1 - это Я", или "Бизнес-операции с ID в интервале 1..100 - не редактируемые". Но тут уж никакое автоинкрементное поле недопустимо.

Sergey13 (2006-04-07 09:58:00) [2]
2[41] Jeer © (06.04.06 17:23)
Это наверное когда в коде присутствуют ссылки на конкретные ID-шники? Иногда такое надо. Так это "лечится" либо введением уникального НЕавтоинкрементного поля "Код", либо принудительной записью ИД из негенерируемых значений (для реального автоинкремента это вроде невозможно).

Курдль (2006-04-07 09:29:00) [3]
Jeer © (06.04.06 17:23) [41]! Пожалуйста! Объясните мне, что такое "Пересборка базы"! :(
Ночь не спал! :(
Я не могу себе представить, что это... Backup/restore? Экспорт/импорт дампа?

Jeer (2006-04-06 17:23:00) [4]
Пересборка базы - в итоге name в справочнике тот же, но ID другой - autoinc свое слово сказал.
В результате - "рассогласование".
Лечимо, но с учетом "правильной" реорганизации базы.

Курдль (2006-04-06 16:41:00) [5]
А мне не понятен термин "рассогласование базы."
Jeer ©! Не поясните, что за беда? Мож у меня, пока я пребывал в беспечном неведении, все базы рассогласовались и ващще распоясались без присмотра? :)

Sergey13 (2006-04-06 16:35:00) [6]
2[38] Jeer © (06.04.06 16:26)
> относительная уникальность.
Это типа номера позиций в накладной или что-то другое?

Jeer (2006-04-06 16:26:00) [7]
Johnmen © (06.04.06 15:24) [34]

> Реализация autoinc самим сервером

> Поэтому считаю, что его надо переваривать...:)
>

Спорить не буду - autoinc на сервере - почти гарантия от "наложений".
Не перевариваю по другой причине - относительная уникальность.
А точку zero - восстановить бывает сложно, если вообще возможно.
В итоге - рассогласование базы.

Курдль (2006-04-06 16:11:00) [8]

> Sergey13 © (06.04.06 16:08) [35]
> Я, наверное, так же как и Ты (ты). 8-)

Ура! Счастье есть! Впервые за долгие годы со мной кто-то согласился! (шютка) :)
Но, если честно, вся эта возня забылась, как только перешел на ADO.NET - там все разруливается без руковмешательства.

Sergey13 (2006-04-06 16:08:00) [9]
2[33] Курдль © (06.04.06 15:19)
> Как бы Вы (вы) исполнили такую задачу?
Я, наверное, так же как и Ты (ты). 8-)
"Не применяя его по назначению" я указал для того, что в момент взятиязначение оно пока не применяется, а только резервируется. Применится ли оно потом зависит от многих факторов - например нажмет юзер "ОК" или "Отмена". Но применив это значение я практически гарантирован от коллизий.

Курдль (2006-04-06 16:08:00) [10]
Строку DataSet.ApplyUpdates([DataSet1, DataSet2, DataSet3, DataSet4]);читать, как DataBase.ApplyUpdates([DataSet1, DataSet2, DataSet3, DataSet4]);

Johnmen (2006-04-06 15:24:00) [11]

> Jeer © (06.04.06 15:08) [32]

Да, этот способ описан в соотв.литературе. Но, ИМХО, для продуктивной работы с полноценными SQL серверами, неприемлем.
Реализация autoinc самим сервером - гарантия надёжной работы и сведение к минимуму эффектов от ошибок разработчика приложений.
Поэтому считаю, что его надо переваривать...:)

Курдль (2006-04-06 15:19:00) [12]

> Sergey13 © (06.04.06 14:14) [31]

> Насколько я понимаю, select from rdb$database - в данном
> случае просто способ вернуть значение на клиента не применяя
> его по назначению.

Сдается мне, что заявление применить по назначениюв данном контексте попахивает субъективизмом. Все зависит от принятых методов обработки данных. Меня заинтересовала эта дискуссия, поскольку появилась возможность узнать альтернативные моему, способы. Приведу конкретный пример. (Такой же я как-то приводил в похожем обсуждении).
Имеем форму ввода нового физического лица. Ничего особенного - несколько контролов ввода ФИО, пола, даты рождения и т.п. Тройка гридов для ввода телефонов, адресов (домашний/рабочий), паспортов (РФ/загран). Как бы реализовал я. 4 датасэта + 4 датасоурса + 4 апдэйтобжекта. Пока никаких возражений? Приложение получает от сервера ID физ.лица. Юзер заполняет необходимые поля. Все новые строки всех датасэтов получают этот ID (кто в качестве PK, кто в качестве FK). Юзер нажимает "ОК" -> DataSet.ApplyUpdates([DataSet1, DataSet2, DataSet3, DataSet4]); Все!

Как бы Вы (вы) исполнили такую задачу?

Jeer (2006-04-06 15:08:00) [13]
Тем не менее, в общем случае, не пользуясь autoinc или триггерами, вполне возможна организация "чистым" SQL такого псевдо-autoinc поля с возвратом ID

Обработка исключительно на клиенте:

-Select max по PK; result := fields[0].AsInteger + 1;
-Попытка вставки result до удачи заданное число раз

Так сказать, конкурентый доступ к max+1 записи.:))

Ethernet - тоже система доступа к моноканалу на основе конкуренции.

Данный метод давно опробован, тестировался и использовался неоднократно.
Основание, слегка личное - не перевариваю autoinc и есть за что.

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

Sergey13 (2006-04-06 14:14:00) [14]
2[29] sniknik © (06.04.06 13:45)
> причем судя по названию в ней хранятся инфа о файле базы какаята
О базе вроде (ну или о первом файле).

RDB$DATABASE defines a database. (LangRef)

О файлах вроде rdb$files.
RDB$FILES list the secondary files and shadow files for a database.

Так что не думаю что в RDB$DATABASE окажется больше 1 записи. Хотя конечно 100% гарантию дает только страховой полис. В Оракле в DUAL тоже можно еще записи вставить если есть желание базу поломать. 8-)

Про "стандартность" я говорил имея в виду "общеупотребительность". Сори за неточность.

2[30] Johnmen © (06.04.06 13:52)
> Стандартно, это NextGenValue= GEN_ID(ID_GENERATOR, 1)
что <> SELECT ... FROM xxx

Насколько я понимаю, select from rdb$database - в данном случае просто способ вернуть значение на клиента не применяя его по назначению. Иначе то вроде никак не получится.

>Я бы всё же уточнил.
Согласен.

Johnmen (2006-04-06 13:52:00) [15]

> Sergey13 © (06.04.06 13:24) [28]

Стандартно, это NextGenValue= GEN_ID(ID_GENERATOR, 1)
что <> SELECT ... FROM xxx

>Есть стандартный метод получения (гарантированного) следующего значения последовательности/генератора.

Я бы всё же уточнил.
Есть стандартный метод получения (гарантированного) текущего значения последовательности/генератора сразу же после наращивания этого значения.

sniknik (2006-04-06 13:45:00) [16]
> Есть стандартный метод получения (гарантированного) следующего значения последовательности/генератора.
покажи его

если использование RDB$DATABASE стандартно, то я про это не знал
просто после
> select Gen_ID(GeneratorName, Increment) не_помню_синтаксис_IB
в [12] писал пример, и зная о необходимости использования таблици пробежался по системым, выбрал подходящую с одной записью. ее и использовал.

причем судя по названию в ней хранятся инфа о файле базы какаята, а будет база состоять из двух файлов/трех .... т.д. столько записей и будет. (это мой "домысел", влезать в изучение тонкостей IB времени нет) т.е. получается, что гарантировано одной записи может не быть даже при этом (а что бывает если не одна показано на примере RDB$FIELDS)
вот, а ты теперь говориш что это стандарт в IB...? и это рекомендуют к использованию?
(если это правда то считай мое уважение к IB и подобным системам упало ниже плинтуса ;о)), только я думаю ты ошибаешся, рекомендованным этот метод быть не может. рекомендовано и стандартнотам использование генератора в тригере (однозначно одноразово) для автоинкремента)

Sergey13 (2006-04-06 13:24:00) [17]
2[27] sniknik © (06.04.06 13:16)
>вот это мы как раз и выясняем ;о), и если почитаеш ветку, то поймеш что я как раз противник ЭТОГО.
Прочитал и не понял. 8-)
Есть стандартный методполучения ( гарантированного) следующего значения последовательности/генератора. Если его использовать НЕ стандартно, то естественно получишь НЕ стандартный результат. Но в чем тут несовершенство стандартного метода - я не понял.

sniknik (2006-04-06 13:16:00) [18]
> А зачем делать ТАК?
вот это мы как раз и выясняем ;о), и если почитаеш ветку, то поймеш что я как раз противник ЭТОГО.

Sergey13 (2006-04-06 13:13:00) [19]
2[25] sniknik © (06.04.06 12:37)
>а если спользовать с неденичным наполнением, наприммер
SELECT GEN_ID(ID_GENERATOR, 1) AS ID FROM RDB$FIELDS
то результат будет очень интересным

А зачем делать ТАК?

sniknik (2006-04-06 12:37:00) [20]
на ее месте мог быть любой (© брильянтовая рука)

а если спользовать с неденичным наполнением, наприммер
SELECT GEN_ID(ID_GENERATOR, 1) AS ID FROM RDB$FIELDS
то результат будет очень интересным ;о) (а после вопрос в форуме "почему у меня пропуски в "автоинкрементном" поле???" ;о))

прочем такой вопрос может быть и в предыдущем варианте как только количество файлов базы перевалит 1 штуку.

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »