поредни номера

Как го правите този номер с непрекъснати поредни номера? Главния ключ ми се покачва с 1 за всяко вмъкване и пак нямам поредност понеже като се издъни някоя транзакция и губя този номер! Ползвам sql server 2000.

Не ползваш identity а си го организираш сам (например в отделна таблица с броячи(и когато правиш rollback не пипаш брояча.)

Аз го правя така:

INSERT INTO test (id, name) VALUES ((SELECT COALESCE(MAX(id), 0)+1 FROM test), 'xxx');

Everything louder than everything else...

Винаги ми малко неестествен то'а въпрос с поредните номера(т.е. доколкото разбирам става въпрос за ID-то на записите).
От моя скромен опит съм стигнал до извода че идеологията на базата данни не изисква стриктно подръжка на поредност при ID-тата.Кво толкова че ще имаш "дупки" в реда на записите....нали като изтриеш някой запис пак се получава фрагментация....
Виж ако гониш някакви други числа за поредност нпр. като кодове на номенклатура и пр. то тогава става сложно...

Много често иде реч точно за законово определена поредност.

Я се опитай да обясниш на данъчните, че номерата на фактурите ти не са поредни

salle.online.bg/sig

zitat:"Виж ако гониш някакви други числа за поредност нпр. като кодове на номенклатура и пр. то тогава става сложно... "

hm, tshak tolkova slojno ne e:
predstavi si tshe imash tri Tablizi, napalneni sas danni koito refernzirat sas my_ID, Satzart i Language_ID ot njakade si. I tezi Tablizi vseki den se aktualizirvat.

Dannite ot tezi tri Tablizi vlizat v edna peta Tabliza (posledovatelno) i to vseki den s razlitsni danni i tova na 16 ezika. Ako tu njamash edna porednost na dannite e Chaos.

Za da izbegna tozi Chaos pravja mejdinna stapka (Tab_4):
v Tab_4 slagam Dummy Datensatz, transformiram dannite ot Tabliza_1 i generiram My_ID-ta v Tab_4

(DECLARE @sourceTable sysname
DECLARE @destinationTable sysname
SET @sourceTable = 'I_Verdrahtungsart'
SET @destinationTable = 'PropertyText'

DECLARE @myid int
DECLARE @mySatzArt int

DECLARE mycursor CURSOR FOR
SELECT I_Verdrahtungsart.My_ID, I_Verdrahtungsart.SatzArt
FROM I_Verdrahtungsart, PropertyText
WHERE I_Verdrahtungsart.MY_ID = PropertyText.MY_ID AND I_Verdrahtungsart.SatzArt = PropertyText.SatzArt
Group by I_Verdrahtungsart.My_ID , I_Verdrahtungsart.SatzArt
ORDER BY I_Verdrahtungsart.My_ID

OPEN mycursor

FETCH NEXT FROM mycursor Into @myid,@mySatzArt

WHILE (@@FETCH_STATUS = 0)
Begin
UPDATE PropertyText SET PropertyText_ID=(SELECT max(PropertyText_ID)+1 FROM PropertyText)
WHERE My_ID=@myid AND SatzArt = @mySatzArt AND PropertyText_ID is NULL
FETCH NEXT FROM mycursor Into @myid,@mySatzArt
End

CLOSE mycursor
DEALLOCATE mycursor

GO..)

sega moga vseki update na Tab_4 sas Tab_1, Tab_2, Tab_3 tshisto da izvarsha kato naprimer:

UPDATE PropertyText(Tab_4)

SET PropertyText.Text = I_Verdrahtungsart(Tab_1).Text,
Status = 2,
PropertyText.I_Datum = I_Verdrahtungsart.I_Datum,
PropertyText.I_Status = I_Verdrahtungsart.I_Status

FROM I_Verdrahtungsart RIGHT JOIN PropertyText ON
I_Verdrahtungsart.My_ID = PropertyText.My_ID and PropertyText.Language_ID = I_Verdrahtungsart.Language_ID
WHERE PropertyText.Text <> I_Verdrahtungsart.Text
AND PropertyText.My_ID is NOT Null .......

i sega si palnja Tab_5 ot Tab_4 kato selektiram totshno kakvoto mi trjabva.
oshte dva DTS-Paketa i za drugite dve Tablizi po sashtia natshin (bez dummy Satz).
I vsitshko e tshisto i prilejno.

Moje bi ne e nai elegantnija natshin, no v momenta druga ideja ne mi idva...

about: "hm, tshak tolkova slojno ne e:"...

..само некви си 5 таблици и 16 врътки и много внимание...

Майтап..
Няма спор по това което казвате... но аз като един ламер намирам за много глупаво да се връзва номер който ми трябва да е задължително пореден, с ID-то на записа в таблицата....
Все едно номера на колата ми да съвпада с номера на касовата бележка дето съм го платил...

Е аз не видях някой да говори за такова съвпадение.

Представи си обаче, че номерата на касовите бележки ги генерираш в транзакция и транзакцията бъде отказана.

Ако номерата на касовите бележки не са поредни данъчните ще ти отрежат главата.

salle.online.bg/sig

Да отрежат главата на Били че чупи транзакциите....






..и топките и топките...провикнал се заспалия администратор на задната седалка...

ok , s tozi primer stava vapros za podgotvjane na milion i polovina danni v edna Tabliza, predi izlizaneto im ot SQL- Server, zaradi vlizaneto im v druga objekt orientirana DB.
Pri takiva Dimensioni na danni-transfer strada Performansa, zatova predpotshitam da programiram, no ako stava vapros za 1000 kasovi belejki bich go napravila kakto Blanding Castle (pogledni gore)

Драматизираш! Просто отчиташ дупките като "унищожени". Стандартна практика е да си оставиш 2-3 фактури от предишния месец за врътки до 15-то число на текущия :-))

cheers,
</wqw>

Абе така е ама до време ....
Докато ти цъфнат на проверка примерно

salle.online.bg/sig

Това сякаш на първо четене ми допада като решение. Ще се тества:))

INSERT INTO test (id, name) VALUES ((SELECT COALESCE(MAX(id), 0)+1 FROM test), 'xxx');

И на мен ми харесва, но предпочитам id-а да се сетва с тригер, за да не се повтаря навсякъде или да се изпусне понякога.

Ще го забуча в съхранена(защо се наричат така?? другите сякаш са разпиляни?) процедура.

"съхранена(защо се наричат така?? "

Защото се съхранява (разбирай по-добре се пази) на Сървъра а не в клиентската част където (на теория) има по-голяма опасност да се скапе нещо.

Етимологията на термина явно е свързана с времето когато Сървърът беше нещо Голямо Супер скъпо и съответно по презумция Високонадеждно а Клиентските станции точно обратното (много на брой, малки, нестабилни ,несигурни и т.н.)

salle.online.bg/sig

Отлично обяснение , сега как е възникнало името на разширените процедури(dll код който също разширява функционалност и пак си седи на сървъра на сървъра)?

Ми ти сам си си отговорил - "разширени" са, не защото са по-широки от другите, а защото разширяват функционалността.



Mixy