Имаше нужда да се запознаете с Oracle
256M RAM - можете. Вкъщи имам само 256, не бързи, но въртят. Стартирам услугата само при необходимост, разбира се. :-)
PS няма да има holivar
Това не е болест или грешка. Дори и трик. Това е предупреждение към небрежния програмист, пряко следствие от версията, че "не е добре да режеш клона, на който седиш". Ако IDE ви предупреди за зацикляне на програмата, безкрайна рекурсия или препълване на стека, това грешка ли е? :)
> Това не е болест или грешка.Не, това е и болест, и грешка. Само не Oracle. :-)
> директно следвайки версиятаМежду другото, не мисля, че изобщо се вписва в версията, дори само защото се среща в същата сесия. И от друга сесия ще има напълно различна грешка (отново не е разработчик)
> Какво е R2? Версия 2 ли е (9.2 или 10.2)
> Тази грешка не се дължи на ключалки. тригери на всеки ред (не знам за IB) в IB всички тригери са еднакви за всеки запис. той чете версиите на записите, свързани с текущата транзакция. И Оракла има проблем, т.к. няма концепция за версия. Не разбира какви данни да вземе.
> Това е предупреждение към небрежния програмист, което директно следва от версията от версията, това не следва по никакъв начин. Това следва от факта, че ако DML засяга няколко записа и в същото време направи селекция в тригера за ред, той ще върне пълен боклук - половината от записите под формата на ПРЕДИ DML-изявлението, половината след. Това също противоречи на принципа, че винаги ще виждаме едни и същи данни за конкретен SCN.
> IB версията просто прави копие на записа вместо вас и измъчва > нея както искаш независимо от другите.IB не знамНяма да споря, само ще попитам. Глоба. Едната сесия промени записа без ангажимент, другата направи същото. След това 2 ангажимента. Какво ще получим? И това правилно ли е?> в IB всички тригери са еднакви за всеки запис. > И няма проблем с четенето на променлива таблицаЗаключавам, че в IB няма понятие за променлива таблица. Има концепция за променената маса. В Oracle и двете концепции присъстват и са различни. Просто не сте разбрали правилно.> > Какво е R2? > Това е издание 2 (9.2 или 10.2)A. Е, тогава имам R2 с 6 пача.
> Е, и IB не беше глупавЕ, не съм казал, че са глупаци. Просто се чудех как са се справили с тази ситуация тогава?> Втората транзакция ще изчака първия комит. "Кой пръв стана, > това и чехли"Е, ако единият направи rollback, няма въпроси, но ако е комит, вторият какво тогава, ще изплюе ли грешка? В [41] си спомням, че отписах грешка, произтичаща от неразбиране на програмист относно липсата на версии. Ето подобна ситуация.
Благодаря за отговорите и съветите. Утре ще отида до Горбушка, надявам се, че ще намеря дистрибутор там. и ще започна да псувам вкъщи. над себе си най-вече :0)))
ORACLE има едно добро предимство. Възможност за извършване на SELECT над SELECT. Много е удобно дори само за развитие. Например искате да знаете колко записа ще ви върне определена заявка. Напълно възможно е да напишете нещо подобно: SELECT COUNT(*) FROM (SELECT . FROM . WHERE . ). Любопитно е, че не само SELECT и SELECT са възможни, но и комбинацията от резултатите от няколко заявки в заявка от по-високо ниво чрез псевдоними на заявки.
Нещо такова:
SELECT A.ID, A.NAME, B.S_AMOUNT FROM T1 A, (SELECT ID, SUM(AMOUNT) S_AMOUNT FOM T2 WHERE .GROUPBY ID ORDER BY ID) B WHERE A. > и клаузата ORDER BY също могат да се използват в подзаявка. Това ви позволява да сортирате вътрешния набор преди сливането (направих това) и значително да ускорите резултата.
Вярно е, че когато работих с ORACLE, се натъкнах на едно много странно нещо: оптимизаторът в определена ситуация може да превърне некорелирана заявка в корелирана (с допълнително произволно условие във вътрешната заявка). Като цяло оптимизаторът ORACLE ме обърка няколко пъти с непредсказуемостта на своите решения. Като цяло, разбира се, готин сървър. Жалко, скъпи адски много.
Кой оптимизатор?
> SELECT COUNT(*) FROM (SELECT . FROM . WHERE . ).Е, като цяло вероятно всеки модерен сървър може да направи това.> ИЗБЕРЕТЕ > A.ID, A.NAME, B.S_AMOUNT > ОТ > T1A, > (SELECT ID, SUM(AMOUNT) S_AMOUNT > FOM T2 WHERE . ГРУПИРАНЕ ПО ID ORDER BY ID) B > WHERE > A. >И това е един вид запис за присъединяване, вероятно също във всеки сървър. Дори Local SQL има (не говоря за вложен избор)> Като цяло оптимизаторът на ORACLE няколко пъти ме обърка с непредсказуемостта на > техните решения.Това е от неразбиране или от неразбиране. Но понякога Оракла наистина взривява покрива. Но след като сте променили малко молбата, вие го карате да я преглътне.
> Оптимизаторът на ORACLE ме обърка няколко пъти с непредсказуемостта на решенията си там има настройки - вагон и малка количка всичко е предвидимо, но методът за прогнозиране е нетривиална формула от настройки + зареждане + ред на свързване на таблици + количество и разнообразие от данни в таблиците + релевантност на статистиката на индекса + .
Ще ви кажа нещо ужасно: той може да направи товадори глупавия Access.
Кой оптимизатор?
Не знам. Много от тях? Работих с ORACLE 9i. Не е достатъчно дълго, за да се справя сериозно с оптимизаторите. Но имах многостепенни заявки (с генериран текст). Какво се използва по подразбиране? Доколкото разбрах тогава: "икономическият принцип на оптимизацията" (или нещо подобно, не помня - прочетох го на английски в описанието).
Но имах ситуация, над която моят приятел и аз се озадачавахме цял ден. Точно този, за който говорех: безвредна некорелирана заявка беше изпълнена от ORACLE като корелирана. Тоест, той многократно извиква подзаявката, въпреки че резултатът от всяко извикване трябваше да бъде очевидно един и същ (в условията на подзаявката полетата от външната заявка не бяха използвани по никакъв начин). Само когато грубо разбрахме как ORACLE се опитва да разсъждава, изхвърлихме едно допълнително (тривиално) условие от подзаявката и всичко работи правилно. Възникна допълнително условие поради факта, че текстовете се генерираха автоматично и в определена ситуация две различни условия можеха логично да се дублират - в началото не видях това като престъпление.
Ще ви кажа нещо ужасно: дори глупавият Access може да направи това.
Много се съмнявам, че Access в синтаксиса поддържа псевдоними за подзаявки. Дори и да е така, колко нива на влагане на подзаявка позволява Access? И колко бързо е? Може ли Access да приеме клауза ORDER BY в подзаявка?
Сравнявам с IB. В него, за съжаление, е невъзможно да направите заявка над заявка, въпреки че можете да излезете чрез съхранена процедура с SUSPEND. Знам, че MS SQL също може да прави заявка върху заявка, но аз лично не съм правил такива неща в MS SQL.
Просто ORACLE го прави прекрасно. Просто исках да кажа това.
промяна на събитията на сесията "10053 проследяване на контекста на името завинаги, ниво 1"
и четене на файла за проследяване през зимна вечер.
> но дори и да има версия (между другото, колко > такива версии са възможни за един запис?), то очевидно някак си е различно от > в IB > може би само една дума означава различни неща?По принцип в Oracle заключване възниква само (не говоря за потребителски заключвания сега), когато се опитвате да промените вече променен запис във втората сесия. Но ако записът е избран, не се появяват заключвания. Дори ако през времето (не помня точно правилното име) неизменността на данните по време на транзакцията (първата сесия), тези данни се променят в друга сесия, първата продължава да работи със старата си версия. Orakl извлича тази информация от регистъра на промените или нещо подобно. Но това вече е от темата "Нива на изолация на транзакциите" За някои "термини" моля не ритайте, не съм админ. :)
> Те са 2. По цена и по правила. за пари и концепции :)
И няма нужда да се съмнявате, можете да проверите. Отговорът е подкрепа.
>>Въпреки това колко нива на вложени >>подзаявки позволява да следва Access?
Проверени 10, след това уморен.
>>Може ли Access да приеме клауза ORDER BY в подзаявка?
Може би. За какво? Защо в Oracle?
>>В ORACLE е просто страхотно.
Да, и много повече се прави разумно, аз лично се радвам да се занимавам с този (9.2) продукт :-)
> >>Може ли Access да приеме клауза ORDER BY в подзаявка? > Може би. За какво? Защо в Oracle?Срещал съм това само веднъж досега. Написах дървовидна селекция с ред по братя и сестри, след това добавих rownum, след това всичко трябваше да бъде отсято исортирайте подрязаното дърво по братя и сестри. Е, най-външната селекция естествено вече не беше дървовидна, така че сортира за втори път според предварително избрания rownum.
> Сравнявам с IB. В него, за съжаление, заявката над заявката > невъзможно е да се направив двойка е възможно
> Не разбирам какво означава "сменяема таблица".В Oracle има 2 типа тригери: тригери на ниво оператор и тригери на ниво ред (на всеки ред), всеки от тях е съответно разделен на още 2 вида (подвид, както искате): преди промяна и след промяна. Естествено, всеки от тях може да действа при вмъкване, актуализиране, изтриване и в комбинация. Да приемем, че искате да актуализирате таблица с клауза where, която включва множество редове. Алгоритъм: 1. Изпълнява се преди ниво на оператор. 2. Започва сканирането на таблицата (индекса), намира се първият ред, който отговаря на условието. 3. Изпълнява се преди ниво ред. 4. Правят се промени. 5. Флагът на променената таблица е поставен. 6. Изпълнява на ниво ред след. 7. Търси следващия ред, който отговаря на условието. 8. Ако бъде намерено, преминете към стъпка 3. 9. В противен случай флагът на променливата таблица се изчиства. 10. Изпълнява се след ниво на изявление.
Ако възникне грешка на някоя от стъпките, тогава цялата актуализация на фиг. Изглежда, че не съм забравил нищо.
> За данни, IMHO, са достатъчни две състояния - преди и след промяната. > Защо ви е необходимо състоянието „в процес“, ако не ви е грижа за тях > по това време не се обръщат (мутации, etit!)? Какъв е смисълът > От него? Можете ли да дадете пример?Нямаме нужда от състояние в процес, но понякога трябва да обработим текущите стойности на низ. Например в MSSQL се формират вмъкнати и изтрити таблици. Ако трябва да анализирате коректността на записа за актуализация, трябва да го направитенамерете в двете таблици и след това само сравнете. Тъй като може да има много записи и различни условия за сравнение, използвахме курсори. Ако трябва да поправите нещо, трябва да направите актуализация отново (не помня нито целевата таблица, нито вмъкнатата таблица, не съм работил с MSSQL от дълго време, кой знае, ще ме коригират). В Oracle създавате тригер на ниво ред (преди), извършвате проверка и ако трябва да коригирате нещо, напишете например така: :new.fld := :old.fld + 1 + всичко това се прави в същото сканиране.> Заключавам, че „в процес“ е действителното заключване.Не, това не е заключване. Веднага след промяна на първия ред от групата флагът се задава, а след като се промени цялата група редове, флагът се нулира. И ако изборът идва от таблица със зададен флаг, тогава получавате същата грешка относно "мутация".
Всички да избягат у дома, ако има нещо, останалите утре.
oracloid (06/07/06 20:15) [78] За тази ситуация е важен редът, в който се променят записите, който може да бъде изрично определен в това трето попадение. И тъй като редът е неизвестен, тогава заявката, посочена в тригера, е безсмислена. Но за да бъдем по-конкретни, стойностите от променените записи трябва да са нови, а стойностите от недокоснатите трябва да са стари, тъй като за някои редове тригерът вече е работил, а за някои - не. За текущия задействан запис - стария, т.к ПРЕДИ задействане.
> След като отговорите на него, всички въпроси ще изчезнат Отговорено. Не си тръгна.
и за анализа на SET от променени записи BEFORE и AFTER DML има тригери BEFORE и AFTER STATEMENT-LEVEL.