Здравейте! Използвам FireBird и забелязвам следното: Имам една таблица (№1),
в която записвам история на извършените актуализации в друга таблица (№2). Всъщност сложил съм after тригери на таблица №2, които добавят запис в таблица №1 при всяка актуализация на №2. Прецених, че PRIMARY KEY за №1 не ми е нужен, тъй като записите ще са ми необходими само във физическа последователност (демек по RDB$DB_KEY) за репликация към друга БД. Докато си правих тестове със записите в №1 се натъкнах на това, че като ъпдейтна запис, който физически не е последен - става последен, а друг път - не. Не схващам логиката на този RBD$DB_KEY. Някой знае ли нещо по въпроса?
Благодаря предварително.

"Физическа последователност на записи" е нещо, което не съществува (или поне е нещо много по-различно от интуитивната представа, която хората имат).
Релационните бази данни работят с МНОЖЕСТВА, а не с редове.
Ако искаш да имаш някаква подредба, трябва ти да си я въведеш.
Дали ще е по последователни числа (напр. от генератори), или по време, или нещо друго ти си решаваш и ти го определяш.
Не можеш да разчиташ на RBD$DB_KEY, защото той си се ползва от сървъра за свои цели и ти гарантира устойчивост само в рамките на текущата транзакция.
Повече за RBD$DB_KEY можеш да прочетеш в

Съдържаниет е скрито
Влезте за да го видите

Редактирано от NDeu на 01.02.05 18:22.

Thank You!!!

"Не можеш да разчиташ на RBD$DB_KEY, защото той си се ползва от сървъра за свои цели и ти гарантира устойчивост само в рамките на текущата транзакция. "

От всичко което ми каза, всъщност само това ми беше неясно. И все пак си мисля, че редовете от таблиците в базата трябва да имат някакъв вътрешен уникален адрес. Как иначе се осъществява връзката между индексите и даден ред от таблица?

Мерси за линка!

В отговор на:

---

И все пак си мисля, че редовете от таблиците в базата трябва да имат някакъв вътрешен уникален адрес.

---

Мерси x 10! От линковете ми става ясно за структурата на RDB$DB_KEY.
Досега винаги съм работил с PK и генератори, но ме зачопли любопитството :)