>За скороста и за роллчетата няма спор....

Че за какво трябва сървъра да се натоварва да изпълнява 100-тина реда сорс при положение че това може да се реши на един ред. Какво ще стане ако към така настроен сървър се вържат няколко стотин конкурентни user-а!. И защо прави по не-знам-си колко хиляди rollback-а! Не си ли задаваш тези въпроси и не те ли навеждат на мисълта че нещо не е в ред.

> ... е 100% стабилно дуракоустойчиво и гарантира ...

Има едно основно правила във всяка една област на техниката:
Колкото по сложна е една система - толкова повече нараства вероятноста от колизия в системата!
За програмирането това ще рече Колкото повече сорс написан - толкова повече бъгове и вероятност от неконтрилируеми грешки

Настина трябва да се позамислиш относно за какво се ползват SP-тата и изобщо DB сървърите.

--
Miroslav Penchev

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

В отговор на:

---

това което използвам аз е 100% стабилно дуракоустойчиво и гарантира че няма да има колизии и дабъл ID-ta...

---

> А ти само разнасяш камъните от тука там и обратно.

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

--
Miroslav Penchev

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

Ok Ok.... и все пак си мисля че аз наблюдавам факти ... а не въртя теории от книжките ...... сигурно не разбрахте че имах впредвид системи в които вероятноста за конкуретен достъп е 1 / 10 000... а не за E-Pay...И ако хората с големите претенции четат по внимателно ще раберат че осъждаме вариант а не hi-tehnologi method...за дадения проблем....

Ако не носех камъните на гръб а разчитах на теорията за преодоляване на гравитацията то тогава да бях станал милионер от телефони обаждания на клиенти от рода "аве тука едно прозорче с червено..."...но няма такова нещо...дори нещо напротив... зорлем не мое да го скапеш...

Да не подхващам темата -> моя стил колко усилия ще ноложи ако искам да мина на друга база ...и разните специфики които ми предлагате тука....

Несериозно е да се мисли само за конкретния проблем.... все си мисля че програмисти като Nd... на много трябва да се сещат едно решение какво ще предизвика при ъпдейт..миграция и прочие...

аре че мразя да филосовствам....приемаме че все още съм ламер ....щото нямам и претенции за повече.....

А може би както някой беше споменал по горе....не що за тъпите програмисти....та и аз май ше мина в тая група....


И още нещо --- като казвате за повечето код - повече бъгове и т.н....

ПОВЕЧЕ БЪГОВЕ ама ЧУШКИ.... ако караш кола в 5000 екстри каква е вероятноста всеки ден да си на сервиз... щото аз на мойта кола разчитам само на окачването и на двигателя и неам проблеми.....така че никви тригери никви вювъри... и алабала подобни......факта е че всичко върви.... и кода е копи-пейст....и що ли само логически бъгове имам... аа забравих ..техническата част я поема сървъра.... много умен бреййй...

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

Само така - ма....та му е в ъпдейтването.

Ако някой разчита на стари знания - няма да го бъде като програмист дълго време. И забравете тези приказки за тъпите и умните програмисти. Добрите програмисти се учат постоянно (аз също )!

--
Miroslav Penchev

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

...мммда.....да се надяваме....пак е некав напредък... като се има впредвид че от ентусиазъм първоначално пишех програмите на тетрадка щото компютър имаше само в училище... 1 за 50 души....какви врмена беха...даже ме беха зключили у даскалото.........по погрешка....:))))

Е, извинявай
Най-малко исках да прозвучи лично и пренебрежително.
Метафората със Сизифовите камъните я включих, в смисъл че в процедурата ти прехващаш грешките и ги предаваш на клиента като данни (RESCODE), нещо което и сървъра прави макар и като ексепшъни. Но както и да е, това не е принципно. Такъв подход си избрал, такъв ползваш.
Проблема IMHO е че тези грешки ти ги предизвикваш с:
select Max(ID)+1 ...
insert into ...

Успех

Както вече споменах процедурите са част от една по голяма идеология....
Та в този смисъл RESCODE не отива към клиента , а аз си го прихващам на по горно ниво...И за да съм по точен ще ти кажа че при моя софтуер шанса клиента да получи ексепшън е 1 / нтч (нтч нема такова число)...
което може би се оказва най важно за самия клиент....и за разлика от датекс или микроинвест аз не седя по цял ден на телефона да обяснявам на клиента как проблема бил при него че ала бала сетингите простотии и прочие...


А... има... има ексепшъни....но няма пак да намесвам Gоd Били...

Nd...само от спортна злоба да те попитам..

попадам на таблица с id ot 100 do 150 например...
прилагам твоя съвет с тригерите.
опитвам се да въведа 101 нови записа но естествено гърми щото 101 се дублира...но това не е фатално...
ако сетна генератора на 151 и пак се опитам да добява N-записа..но в
N+205 имам грешно поле и става хоп-стоп...генератора не признава Rollback...
и тогава остава фрагмент бая голям..което също не е трагедия ...
Но представи си че от горе спорещите за разпределение на ID-тата на зони им се случат такива "ДУПКИ".... егати и базата ....а???
А да предположим че имаме таблица склад и таблица номенклатури и в склада има полета IDSTOR и IDNOM....при моя метод в имам 2 фрагмента на 100000 записа и при IDSTOR = 5901 -> IDNOM = 5900....
Лесно ще ти докажа че тази разлика по голяма от 100 е доста затрудняваща някои дейности по базата да не говорим че може да се случи разлика с цял разряд.....

Но това са само "мисли на глас"... сигурен съм че твоите аргументи ще са по силни....Л))))