DrPass ©   (07.10.08 19:01) [38]


> Очень хорошо. Практика - критерий истины. Согласны?


Нет, не согласен. Критерий истинности - всегда задача. Я не зря спросил именно про искусственное разделение всего объема на порции по N операторов. Допустим, у меня есть задача вставить, скажем, 20000 записей.
В зависимости от того, что надо сделать, если 15732-ая не вставилась, я и буду строить логику - если требуется откатить все изменения, то и транзакция будет одна.

Правильный$Вася   (07.10.08 18:50) [37]

Ну так по сылке говорят "не делайте". А почему - не говорят. Меня интересовала ссылка на "почему". Например, тот же Кайт, рассказывая про оракл, честно говорит, почему невыгодно при массовых операциях делать commit после каждого оператора. Но точно также и говорит, что искусственно разбивать большое обновление на кучу мелких транзакций еще более невыгодно.

>Правильный$Вася   (07.10.08 18:50) [37]
>http://www.ibase.ru/devinfo/dontdoit.htm
>пункты 7 и 8

>7. Не надо делать коммит после каждой записи, если это не требуется по >смыслу

Абсолютно справедливо. Однако о каком "смысле" идет речь при настырном трындеже "лучше резать по кусочкам, чем сразу в мясорубку" ?

>8. Не надо делать commit после вставки каждой записи, если вы их >вставляете больше 10 за один раз

Никто и не спорит. Только опять же кто, где и когда скажет о сабже, в какой момент и поскольку надо вставлять за раз ?

"За что ж аборигены съели Кука ? О том ни слова. Молчит наука" (с)

>kaif ©   (07.10.08 18:13) [34]
>Временные таблицы - это стиль MSSQL,  а не IB.

Ашот, не надо метром мерять объемы, а ? Есть задача и надо найти для ее решения оптимальный способ. А в "стиле" это или нет - это уже эстетство, в данном случае к делу никакого отношения не имеющее.

>Johnmen ©   (07.10.08 20:02) [39]
>А на самом деле Игорь занимается любимым делом - занудством :)
>Конечно же позанудствовать можно и даже бывает нужно. Но чувство меры >не должно отказывать...

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

А автор тем временем засох)..

Или сбежал - страшно стало от затеянного ..

Ни ответа от него , ни привета ..

> Игорь Шевченко ©   (07.10.08 20:03) [40]


> Допустим, у меня есть задача вставить, скажем, 20000 записей.
>
> В зависимости от того, что надо сделать, если 15732-ая не
> вставилась, я и буду строить логику - если требуется откатить
> все изменения, то и транзакция будет одна.

Игорь, это само собой разумеется. Но нас этот вопрос вообще не должен интересовать, т.к. логика обработки ошибок - дело сугубо индивидуальное, тут миллионы вариантов, и обсуждать их без конкретной постановки задачи нет никакого смысла. Мы вообще-то говорили о производительности вставки записей в общем случае, без изысков и дополнительных условий.
Да и вы вообще-то не так давно совсем в другую сторону вели (вот тут я не ссылочку, а цитатку приведу, не возражаете?)

> ну понятно - black voodoo. Желающие подкручивать гайки без
> хлеба не останутся. Но все-таки - насколько мне известно,
>  IB не запускает сборку мусора после каждого commit, версии
> все равно зависят от количества одновременно стартовавших
> транзакций - какая физика механизма, что при транзакции
> "пакетом" быстродействие выше ?

А вы теперь перед очевидными доказательствами сразу решили в кусты слинять, что-то там про конкретные задачи? ;-)

> Сергей М. ©   (07.10.08 20:35) [43]
> А автор тем временем засох)..

А зачем он нам? Мы и без него неплохо пообщаемся :-D

DrPass ©   (07.10.08 20:38) [44]


> А вы теперь перед очевидными доказательствами сразу решили
> в кусты слинять, что-то там про конкретные задачи? ;-)


Ну так физики-то так и нету ? А практических примеров я тоже могу. Давай продолжим дискуссию с поста [13]

> Ну так физики-то так и нету ?

Какая физика? Сегодня вся физика в Стокгольме была :)

MsGuns ©   (07.10.08 20:29) [42]
>kaif ©   (07.10.08 18:13) [34]
>Временные таблицы - это стиль MSSQL,  а не IB.

Ашот, не надо метром мерять объемы, а ? Есть задача и надо найти для ее решения оптимальный способ. А в "стиле" это или нет - это уже эстетство, в данном случае к делу никакого отношения не имеющее.

Сергей, ты неправ. Оптимальное решение в MSSQL и в IB могут оказаться просто прямо противоположными.

Так как IB версионник, а MSSQL - блокировочник.
В MSSQL временные таблицы используются повсеместно, возможно, как лучший способ избежать эскалации блокировок. Временные таблицы можно  даже создавать в хранимых процедурах, а в IB так действовать не принято. Я даже не уверен, что в IB можно использовать CREATE TABLE  в ХП (может в каких-то поздних версиях можно, я не в курсе, так как никогда этим не пользуюсь).

Поэтому и решения для этих двух серверов в данном случае могут быть разными. Я лично в IB никогда не пользуюсь временными таблицами.

И я против таких подходов в IB.
Объясню почему.

При импорте данных наиважнейшими обстоятельствами являются:

1. ссылочная целостность данных
2. скорость.

Временная таблица никаких преимуществ в версионниках в смысле блокировок не дает,  так как никаких блокировок в версионниках попросту не бывает, а при INSERT даже Lock-конфликтов (конкуренции за апдейт одной записи) не предвидится. Так что временная таблица для импорта в версионнике - полный маразм, перестраховщина и излишество.

А вот создавать временную таблицу и вешать на нее foreign key есть еще больший маразм, так как это потребует кучи дополнительных ресурсов и еще больше замедлит импорт.
А если не вешать foreign key, то я не знаю, как обеспечить ссылочную целостность при импорте.
В MSSQL многие вообще не используют foreign key, а проверки делают в триггерах. Старые версии MSSQL (может я ошибаюсь) про декларативную ссылочность вообще ничего не знали, а некоторые учебники до сих пор не рекомендуют ее юзать, предпочитая делать все в триггерах.
А в IB всегда все было прямо наоборот. Декларативной ссылочной целостности уделялось много внимания, а в триггерах заниматься этими проверками в IB просто не рекомендуется по ряду причин. И первая из них - триггер работает в контексте транзакции, а внешний ключ - вне контекста транзакции. Поэтому в IB триггер не обеспечивает со 100% вероятностью ссылочной целостности, а внешний ключ - обеспечивает.

Плюсов же во временной таблице я никаких не вижу вообще.

Я писал десятки программ, в которых приходилось делать импорт в IB,  в некоторых до миллиона записей. Ни разу временные таблицы я не применял и применять (в IB конкретно) не собираюсь.

> kaif ©   (07.10.08 22:10) [48]

Да-да.
В IB до 7.5 и в FB до 2.0, как минимум, не было "встроенных" таблиц. Выполнять DDL команды (в т.ч. CREATE TABLE) в SP недопустимо. Менять структуру БД, создавая таблицу, например, "в рантайме" категорически не рекомендовано. Особенно при незнании определенных нюансов и особенностей.

Охохохохонюшки..
Я ему при пльзеньское, он мне про златолюбие блондинок.

Причем здесь вообще форин, а ? Ну какая разница, каким макаром всталять записи в таблицу - хором (запросом Insrt to select from) или поодиночке с точки зрения ссылочной целостности, а ?

Далее. Про "полный маразм, перестраховщину и излишество", т.е. временные таблицы.

...

Фух, начал писАть примеры, наваял два экрана и плюнул ;(
Ну почему тебе надо объяснять очевидное - что лучше во временной таблице, к которой даже теоретически не может быть попыток доступа из других коннектов, собрать все добавляемые записи, а после этого запустить ОДИН запрос и при этом ВСЕ ДАННЫЕ сервер будет брать непосредственно "в себе", не дожидаясь завершения всякой внешней фигни типа тормозов сетки/клиента и т.д. И если что-то не получится, то откатит всю транзакцию. Понимаешь - ВСЮ ! Т.е. все стотыщмильонов записей. А не "аварийную" порцию в твоем "хирургически-традиционном" методе. Во-первых, представлю, как сервер собирает и ХРАНИТ ДЛИТЕЛЬНОЕ ВРЕМЯ (особенно если клиент "медленный") 49999 версий записей и только при добавлении 50000-й "спускает пар", затем вся эта хрень повторятся для следующей порции и т.д.
Но самое смешное, если при отсылке 999-й порции выяснится, что очередная запись не может быть внесена в БД (хотя бы по причине  нарушения так любимой тобою ссылочной целостности) и поэтому ВСЮ ВСТАВКУ НАДО ОТМЕНИТЬ. Вот что ты предлагаешь в этом случае ? Поднимать бэкап и петь "осанну" "классической" хирургии, принесшей в жертву науки только что склеившего ласты при операции аппендицита несчасного пациента ? И ховаться в жито от разгневанных родных и близких зарезанного ?

>Johnmen ©   (07.10.08 22:29) [49]

Замечательно. Конечно, сабж - это, конечно, нетипичный случай. Но если возникает все же такая необходимость - заливать объемные данные извне - что делать ? Ваш способ нафиг и я объяснил почему.
ИБ у меня попал в разряд "немилостевых" и потому в том числе, что разработчики не удосужились придумать хотя бы что-то напоминающее мелкософтовый DTS

>Johnmen ©  

ИШ, конечно, зануда, я понимаю.
Я - зловредный и ехидный тип, никого, окромя себя не видящий и не слышащий.
А вместе мы дилетанты.

Но что ты скажешь, если и тебе приклеить ярлычок - "догматик" ?

Смотрим:


и вдруг


Ты, Серега, что-то совсем заговорился...
Далее читать посты глубоко верующего в единственность и непогрешимость просто неинтересно.
Хотя, возможно, ты говоришь про что-то своё, не связанное с темой ветки. Тогда - просто бесполезно.

Поймите же в конце концов, что при вашей "хирургии" ДЛИТЕЛЬНЫЕ ПИШУЩИЕ ТРАНЗАКЦИИ, против коих так дружно вопят все классики интербизма-файрбердизма, просто неизбежны !

>Johnmen ©   (07.10.08 22:50) [53]

Под "целостностью" я в данном случае (первая цитата) имел в виду не нарушение форинкеев, а нечто другое - когда в БД попадут НЕ ВСЕ записи, а только часть, причем абсолютно неизвестно заранее какая. Что прикажете делать админу БД в этом случае ?

Слушаю с замиранием сердца ;)

> MsGuns ©   (07.10.08 22:42) [51]
> Ваш способ нафиг и я объяснил почему.

Способ не мой, а классический. Легко находится, как указывалось в [39]. Поэтому посылай классиков. И объясняй им же.


> MsGuns ©   (07.10.08 22:47) [52]
> Но что ты скажешь, если и тебе приклеить ярлычок - "догматик" ?

Пожалуйста. Только с обоснованием.

Кистати, в ИБ имеется возможность ссылаться в запросах на внешние таблицы, насколько я помню. Эге ж ?

> MsGuns ©   (07.10.08 22:50) [54]
> ДЛИТЕЛЬНЫЕ ПИШУЩИЕ ТРАНЗАКЦИИ

С какого они длительные??? Очень даже короткие!


> MsGuns ©   (07.10.08 22:53) [55]
> Что прикажете делать админу БД в этом случае ?

Я админом не командую. Но если заставят, то просто прикажу прогнать импорт ещё раз.

"Хирургия" вполне обоснованна только в одним случае - если "пакет" порезать на независимые логически завершенные (т.е. целостные) "порции" приемлимых размеров. В этом случае клиент может всегда продолжить прерванную трансмиссию данных с "аварийного" пакета. Тогда конечно, следует работать исключительно по классической схеме, ибо она реально является самой оптимальной для сервера.
Но в сабже, повторяю, ни слова об этом.