Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Топик навеян периодическими воплями на тему, что "наши временные таблицы - более "временные", чем ваши" ;-) Последний раз тему затронули вчера в соседнем топике. Разговор не ограничивается Oracle и MSSQL, так что апологеты других серверов могут подключаться. Итак, ведем дискуссию о реализации временных таблиц в различных серверах. Для начала заглянем в SQL-стандарт. Там мы видим во-первых деление на глобальные (далее GTT) и локальные (далее LTT) временные таблицы. GTT создаются с помощью CREATE GLOBAL TEMPORARY TABLE. Характеризуются глобальной видимостью метаданных (они лежат в общей схеме) и сеансовой видимостью данных. Т.е. наличие GTT видят все, но каждая сессия работает со своей копией данных. Если посмотреть на существующие СУБД, то почти все реализуют (с тем или иным синтаксисом) эту возможность. Исключения - DB2 (DECLARE GLOBAL, однако видимость метаданных сессионная), а также PostgreSQL и MySQL - нет этой фичи вообще. Один нюанс - MSSQL (и полагаю, что Sybase ASE также) разделяет данные GTT между сессиями. Никто больше этого не делает. LTT бывают <created> и <declared>. Первые создаются через CREATE LTT и характеризуются сессионной видимостью метаданных. Это означает, что две сессии могут создать разные по структуре CLTT с одинаковым имеем. Разумеется, видимость данных тоже сессионная. Oracle не поддерживает CLTT (как минимум в 9i), также как Sybase ASA и InterBase. Второй класс LTT создается через DECLARE LTT и подразумевает видимость (как метаданных, так и данных) только в пределах текущего модуля (SQL client module). Увы, стандартное понятие модуля достаточно туманно/спорно и, похоже, производители предпочитают трактовать DLTT как внутрипроцедурные таблицы. Oracle и MSSQL имеют такую возможность (в том или ином виде), на счет остальных СУБД у меня информации нет. На практике, лично у меня вообще очень редко возникала необходимость во временных таблицах. И если уж и возникала, то исключительно в GTT (сгенерить данные для сложного отчета процедурой и натравить потом на них Crystal Reports) или в DLTT (если процедурный расчет нельзя выполнить за один прогон исходных данных). Допускаю, что CLTT также могут быть полезны при вынесении логики из базы. У меня всего два вопроса. Первый - почему Oracle (и кое-кто еще) не поддерживают CLTT? Есть какие-либо технические проблемы? Или просто сочли ненужными и забили болт? Второй - какого фига мелкомягкие GTT разделяют данные? На кой тогда вообще это надо? Также хотелось бы услышать о ситуациях, в которых люди применяют временные таблицы. Особенно - почему нелья обойтись без них? Если кто-то хочет поговорить о других вещах, как-то: механизмы хранения временных данных или нюансы отработки ON COMMIT { PRESERVE | DELETE } ROWS - welcome. Если я в чем-то ошибся насчет какой-либо СУБД - поправьте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 15:43 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
IMHO Oracle не поддерживает локальные временные таблицы, потому-что это фактически DDL в продакт коде, т.е. очень очень плохо. Возможно MSSQL к этому относится терпимее но в Oracle это настоящий гиморой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 15:47 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Кстати, необходимость во временных таблицах вообще в Oracle возникает крайне редко. Практически любой отчет можно сформулировать одним запросом. И даже если запрос получится очень махровым оптимизатор с ним справится. До введения аналитических функций (8i) проблему представляли запросы типа "нарастающий итог", что касается "деревянных" расширений, они есть уже в 7-ке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 15:50 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
авторПервый - почему Oracle (и кое-кто еще) не поддерживают CLTT? Есть какие-либо технические проблемы? Или просто сочли ненужными и забили болт? во первых идеологическая проблема, на временые таблицы оракла можно вещать вью и тригеры, а это значит что дефиниция этой таблицы должна быть в словаре базы и соответственно не может быть разной для разных пользователей. наверника если задуматся это можно было бы как-то обойти с помощью синонимов и т.п. но поскольку мало кто придумал задачу в которой бы такое понадобилось, то и решать эту "проблему" видно не собираются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 15:57 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)IMHO Oracle не поддерживает локальные временные таблицы, потому-что это фактически DDL в продакт коде, т.е. очень очень плохо. Возможно MSSQL к этому относится терпимее но в Oracle это настоящий гиморой. Об этом я тоже думал. И в курсе, насколько Оракл это не любит. Но фишка в том, что термин "очень плохо" не дойдет до людей, у которых СУБД такие вещи принимает легко. Для них это норма. Думать все начинают уже после того, как что-то не получилось :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:00 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Yo!во первых идеологическая проблема, на временые таблицы оракла можно вещать вью и тригеры, а это значит что дефиниция этой таблицы должна быть в словаре базы и соответственно не может быть разной для разных пользователей. Это не ответ. Ты описал возможности Оракла в отношении GTT. Кто им мешает ввести ограничения для LTT? И вообще, почему нельзя разграничить видимость словаря базы? Например, через namespace/schema + session_id? Т.е. это не идеологическая проблема, по крайней мере, в этом ракурсе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:03 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
авторOracle не поддерживает CLTT (как минимум в 9i), также как Sybase ASA и InterBase. В Sybase ASA есть - CREATE TABLE #TableName в целях совместимостью с MSSQL. Но этим пользоваться не интересно, так как на такую форму записи не навесишь различные параметры времянки (тот же флаг NOT TRANSACTIONAL), как в DECLARE LOCAL TEMPORARY TABLE. авторУвы, стандартное понятие модуля достаточно туманно/спорно и, похоже, производители предпочитают трактовать DLTT как внутрипроцедурные таблицы. Oracle и MSSQL имеют такую возможность (в том или ином виде), на счет остальных СУБД у меня информации нет. В ASA cуществует понятие блоков видимости и атомарности. Так что в этом коде: Код: plaintext 1. 2. 3. 4. 5. 6. 7. авторНа практике, лично у меня вообще очень редко возникала необходимость во временных таблицах. И если уж и возникала, то исключительно в GTT (сгенерить данные для сложного отчета процедурой и натравить потом на них Crystal Reports) или в DLTT (если процедурный расчет нельзя выполнить за один прогон исходных данных). То же самое один в один. Плюс иногда полезно через DLTT предварительно загнать небольшое кол-во многократно используемых и рассчитываемых данных, которые фигурируют в очень сложном и большом запросе, чтобы оптимизатор лишний раз не сходил с ума и видно, что от этого только выиграешь. авторТакже хотелось бы услышать о ситуациях, в которых люди применяют временные таблицы. Особенно - почему нелья обойтись без них? Если кто-то хочет поговорить о других вещах, как-то: механизмы хранения временных данных или нюансы отработки ON COMMIT { PRESERVE | DELETE } ROWS - welcome. Если я в чем-то ошибся насчет какой-либо СУБД - поправьте. В ASA помимо ON COMMIT { PRESERVE | DELETE } есть еще NOT TRANSACTIONAL. Вот и вся разница. Остальное тоже самое. Так же можно и триггера на GTT катать, очень удобно иногда. авторУ меня всего два вопроса. Первый - почему Oracle (и кое-кто еще) не поддерживают CLTT? Есть какие-либо технические проблемы? Или просто сочли ненужными и забили болт? Второй - какого фига мелкомягкие GTT разделяют данные? На кой тогда вообще это надо? Гм - зачем нужны CLTT, когда есть GTT - это гораздо удобнее. Думаю если бы у MSSQL и ASE были GTT, никто этими CLTT и не пользовался бы. Во вторых разделяют, потому как механизм так криво реализован по моему личному мнению. В ASE кстати номер с ## (глобальными MS времянками) вообще не прокатывает - нет там такого. Плюс эти ## у MSSQL имеют нехорошую тенденцию удалятся при завершении той сессии, которая их создала, так что лично я так и не смог придумать им хоть какое то разумное применение (может и плохо думал, кто знает). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:06 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Кстати, необходимость во временных таблицах вообще в Oracle возникает крайне редко. Практически любой отчет можно сформулировать одним запросом. И даже если запрос получится очень махровым оптимизатор с ним справится. Тут согласен, хотя оптимизатор зачастую все же не справляется. Т.е. получается, что богатый набор языковых фич в большинстве случаев отменяет необходимость во временных таблицах. Но так ли это на практике? ЗЫ. Щаз придут фанаты сиквела и все опровергнут ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:07 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
где-то неподалеку слышен тоскливый вой бродячей собаки.. и вот, гаснет свет и двери начинают меедленно открываться.. неужели это снова пришли ОНИ?? страшно? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:16 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
dimitrОб этом я тоже думал. И в курсе, насколько Оракл это не любит. Но фишка в том, что термин "очень плохо" не дойдет до людей, у которых СУБД такие вещи принимает легко. Для них это норма. Думать все начинают уже после того, как что-то не получилось :-( Нууу не надо быть Энштейном, чтобы понять - что одна СУБД воспринимает хорошо, то другая может воспринимать очччень плохо. Только не надо сразу говорить, что это минус. Это может быть и плюс ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:17 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
dimitrТут согласен, хотя оптимизатор зачастую все же не справляется. Т.е. получается, что богатый набор языковых фич в большинстве случаев отменяет необходимость во временных таблицах. Но так ли это на практике? Если оптимизатор в КОНКРЕТНОМ случае не справляется, это задача для тюнинга :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:19 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
я GTT в DB2 использую как правило в качестве меток к записям в пользовательской выборке. Присоединяешь к основной таблице левым джойном - и красота...) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:19 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
ASCRUSГм - зачем нужны CLTT, когда есть GTT - это гораздо удобнее. Чтобы создавать нужные таблицы динамически в сессиях, не заботясь о том, есть ли уже другие с такми же именем. Для меня это нонсенс, правда, но многие по-другому думать не умеют, похоже ;-) К слову, искренне рад за ASA. Хоть и не люблю блокировочники вообще (говорил уже, что готовить не умею), но ASA мне наиболее приятен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:20 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
в MS SQL глобальные временные таблицы лично я никогда не использовал (за ненадобностью, ИМХО), а вот локальные - да. Иногда, для помощи оптимизатору, я разбивал большой запрос с джоинами к многомилионным таблицам на пару-тройку более простых и промежуточные результаты записывал в локальную врем.таблицу. Потом появились переменные типа table и необходимость даже в локальных врем таблицах еще больше снизилась. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:22 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Локальные временные таблицы теоретически могут пригодиться, если каждый раз требуется таблица ДРУГОЙ структуры, но я не могу придумать задачу, в которой это было-бы НЕОБХОДИМО. И в Oracle, минусы от такой фичи существенно перевесят плюсы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:24 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
segunв MS SQL глобальные временные таблицы лично я никогда не использовал (за ненадобностью, ИМХО), а вот локальные - да. Иногда, для помощи оптимизатору, я разбивал большой запрос с джоинами к многомилионным таблицам на пару-тройку более простых и промежуточные результаты записывал в локальную врем.таблицу. Потом появились переменные типа table и необходимость даже в локальных врем таблицах еще больше снизилась. Аналогично. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:24 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Если оптимизатор в КОНКРЕТНОМ случае не справляется, это задача для тюнинга :) Или для баг-репорта производителю :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:26 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
На моей (не очень богатой) практике не было случая, когда не удавалось найти какое-либо приемлимое решение НА МЕСТЕ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:28 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
В MS SQL одно из наиболее частых применений временных таблиц - сказать INSERT INTO #ttable EXEC <какая-то-совсем-чужая-процедура-которую-нагибать-под-себя-страшно-или-невозможно> Кстати, как такие проблемы решают в Оракл, я не совсем понимаю до сих пор. Юзать REF CURSOR ? Дык по нему потом пройтись придется с песнями и плясками курсором, чтобы заюзать в своем запросе в качестве элемента; или я неправ ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:29 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
gardenmanя GTT в DB2 использую как правило в качестве меток к записям в пользовательской выборке. Присоединяешь к основной таблице левым джойном - и красота...) Кстати да, про такое применение я и забыл. Вполне удобно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:30 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
dimitrУ меня всего два вопроса. Первый - почему Oracle (и кое-кто еще) не поддерживают CLTT? Есть какие-либо технические проблемы? Или просто сочли ненужными и забили болт? Я бы сказал так: техническая возможность есть, но я отлично понимаю нежелание их делать. Оракл стремится перенести максимум нагрузки на этап компиляции кода и соответственно максимально разгрузить (и за счет этого убыстрить) этап выполнения. В ситуации, когда одна процедура создает таблицу, а другая делает из нее селект, о таком желании можно забыть. Соответственно, технически такая возможность есть (через динамический SQL), но это надо делать специально. Грубо говоря, компилятор не встраивает поддержку заведомо неэффективного режима. Мало того: уже достаточно давно существует поддержка nested tables, которые аналогичны подобным "сугубо временным" таблицам. То есть: из них можно делать селекты, также с ними можно работать как с массивами. dimitrОб этом я тоже думал. И в курсе, насколько Оракл это не любит. Но фишка в том, что термин "очень плохо" не дойдет до людей, у которых СУБД такие вещи принимает легко. Для них это норма. Вопрос в том, что эти люди даже не пытаются думать об эффективности кода, который пишут. Перейдя на Оракл, люди - типично - начинают пытаться работать с ним именно так, не пытаясь разобраться, хорошо это (для Оракла) или плохо. Поэтому, полагаю, они и на родном сервере не задавались этим вопросом. В такой ситуации я всячески поддерживаю нежелание встраивать "фичу для торможения". Тем паче, что ни малейшей необходимости нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:45 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Alex.CzechКстати, как такие проблемы решают в Оракл, я не совсем понимаю до сих пор. Юзать REF CURSOR ? Дык по нему потом пройтись придется с песнями и плясками курсором, чтобы заюзать в своем запросе в качестве элемента; или я неправ ? А явные курсоры в Oracle НЕ ЕСТЬ ЗЛО ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:48 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) Alex.CzechКстати, как такие проблемы решают в Оракл, я не совсем понимаю до сих пор. Юзать REF CURSOR ? Дык по нему потом пройтись придется с песнями и плясками курсором, чтобы заюзать в своем запросе в качестве элемента; или я неправ ? А явные курсоры в Oracle НЕ ЕСТЬ ЗЛО Да лана... пройтись курсором по тыще строчек - не есть зло ? :) Или есть все-таки какая-то возможность bulk collect-а из REF CURSOR ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 16:50 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Зависит от конкретной задачи. Ходить по 1000 строчек и в MSSQL не гут. Давайте не будем разводить на эту тему флейм, тема так хорошо началась :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:00 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Я не фанат, просто мне интересно как можно что-то делать без временных таблиц. Вот пример куска реального триггера на изменение остатков при вставке проводок автор declare @accstm_c table( bln varchar(15), fond varchar(15), date datetime, acc varchar(30), s dec(19,6), d dec(19,6), c dec(19,6)) insert @accstm_c select bln, fond, date, dacc acc, summa s, summa d, @nil c from inserted insert @accstm_c select bln, fond, date, cacc, -summa,@nil,summa from inserted insert @accstm_c select bln, fond, date, dacc, -summa,-summa,@nil from deleted insert @accstm_c select bln, fond, date, cacc, summa,@nil,-summa from deleted declare @accstm_p table( bln varchar(15), fond varchar(15), date datetime, acc varchar(30), s dec(19,6), d dec(19,6), c dec(19,6)) insert @accstm_p select bln,fond,date, acc, sum(s) s,sum(d) d,sum(c) c from @accstm_c -- изменение остатка, group by bln,fond,date,acc -- дебета и кредита при проводке insert @accstm_p select bln,fond,'20651031', acc, 0,0,0 from @accstm_p group by bln,fond, acc declare @accstm_d table( bln varchar(15), fond varchar(15), acc varchar(30), date1 datetime null, date2 datetime null) insert into @accstm_d select p.bln,p.fond,p.acc, p.date date1, min(s.date) date2 from @accstm_p p, @accstm_p s -- выбираются интервалы дат where p.bln=s.bln -- для вычисления поправок остатков and p.fond=s.fond and p.acc=s.acc and p.date<s.date group by p.bln,p.fond,p.acc, p.date declare @accstm_s table( bln varchar(15), fond varchar(15), acc varchar(30), date1 datetime null, date2 datetime null, s dec(19,6)) insert into @accstm_s select p.bln,p.fond,p.acc,d.date1 date1, d.date2, sum(p.s) s from @accstm_p p, @accstm_d d where p.bln=d.bln -- для вычисления поправок остатков and p.fond=d.fond and p.acc=d.acc and d.date1>=p.date group by p.bln,p.fond,p.acc, d.date1, d.date2 declare @accstm_n table( bln varchar(15), fond varchar(15), date datetime null, acc varchar(30), s dec(19,6)) insert into @accstm_n select bln,fond,date,acc,@nil s -- выборка недостающих состояний from @accstm_p p -- счетов where date<>'20651031' and (s<>0 or d<>0 or c<>0) and not exists(select * from AccState s where p.bln=s.bln and p.fond=s.fond and p.acc=s.acc and p.date=s.date) declare @accstm_v table( bln varchar(15), fond varchar(15), date datetime, acc varchar(30), dp datetime null) insert into @accstm_v select n.bln,n.fond,n.date,n.acc, max(s.date) dp from @accstm_n n, AccState s where n.bln=s.bln and n.fond=s.fond -- выборка дат предыдущих движений and n.acc=s.acc -- для счетов с недостающими остатками and n.date>s.date group by n.bln,n.fond,n.date,n.acc update @accstm_n set s=s.s -- вычисление остатков from @accstm_n n, AccState s, @accstm_v v where n.bln=v.bln and n.fond=v.fond and n.acc=v.acc and n.date=v.date and v.bln=s.bln and v.fond=s.fond and v.acc=s.acc and v.dp=s.date insert AccState(bln,fond,date, acc,dt,cr,s) select bln,fond,date,acc,0,0,s -- вставка недостающих состояний from @accstm_n -- счетов update AccState -- пересчет остатков set s=a.s+s.s from AccState a, @accstm_s s where a.bln=s.bln and a.fond=s.fond and a.acc=s.acc and a.date>=s.date1 and a.date<s.date2 update AccState -- пересчет оборотов set dt=dt+d, cr=cr+c from AccState a, @accstm_p p where p.bln=a.bln and p.fond=a.fond and p.acc=a.acc and a.date=p.date and p.date<>'20651031' delete AccState -- удаление ненужных состояний from AccState a, @accstm_p p where p.bln=a.bln and p.fond=a.fond and p.acc=a.acc and a.date=p.date and p.date<>'20651031' and cr=0 and dt=0 Понимаю что разбираться в таком количестве лень. Суть в том что данные последовательно обрабатываются и в конце используются для модификации рабочих таблиц. При чем используются не по одному разу. Кое-какие запросы можно было бы объеденить через UNION. Но если объединять очень много - читабельность падает. Наверняка нечто подобное(последовательная обработка) приходится делать и на Оракле. Как это обычно делается? Где хранятся промежуточные результаты? Насчет глобальных таблиц - я их использую только в одном случае: допустим когда чего-то понасчитал в обычные временные таблицы, а потом надо это получить в Эксель. Проще всего это сделать через GTT. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:07 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Alex.CzechВ MS SQL одно из наиболее частых применений временных таблиц - сказать INSERT INTO #ttable EXEC <какая-то-совсем-чужая-процедура-которую-нагибать-под-себя-страшно-или-невозможно> Кстати, как такие проблемы решают в Оракл, я не совсем понимаю до сих пор. Юзать REF CURSOR ? Дык по нему потом пройтись придется с песнями и плясками курсором, чтобы заюзать в своем запросе в качестве элемента; или я неправ ? Один из вариантов решения, предложенного в ASA: Код: plaintext 1. Код: plaintext 1. 2. Код: plaintext 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:10 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Alex.CzechВ MS SQL одно из наиболее частых применений временных таблиц - сказать INSERT INTO #ttable EXEC <какая-то-совсем-чужая-процедура-которую-нагибать-под-себя-страшно-или-невозможно> Кстати, как такие проблемы решают в Оракл, я не совсем понимаю до сих пор. Юзать REF CURSOR ? Дык по нему потом пройтись придется с песнями и плясками курсором, чтобы заюзать в своем запросе в качестве элемента; или я неправ ? Ээ.. Заюзать-то можно как угодно. В том числе и через REF CURSOR, если сильно охота. Вопрос в том, что я не понимаю, когда именно случается это "наиболее частое применение". Если у администратора - для решения разовых задач, типа "получить данные - покрутить - покрутить - покрутить", то ораклоиды обычно пользуют Код: plaintext Использовать постоянную таблицу вместо временной, с одной стороны, несколько неэффективно - но с другой стороны, админу (которого в любой момент могут отвлечь на другую задачу) вряд ли хочется думать о времени жизни данных - предпочтет грохнуть таблицу по завершении работы. Ну а конфликта имен здесь не будет в силу такого понятия, как "схема". Если же имеется в виду постоянное применение, в "релизном программном коде" - надо пользоваться стандартными средствами, теми же GTT. Локальные средства здесь - прямой источник ошибок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:10 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
ASCRUS Alex.CzechВ MS SQL одно из наиболее частых применений временных таблиц - сказать INSERT INTO #ttable EXEC <какая-то-совсем-чужая-процедура-которую-нагибать-под-себя-страшно-или-невозможно> Кстати, как такие проблемы решают в Оракл, я не совсем понимаю до сих пор. Юзать REF CURSOR ? Дык по нему потом пройтись придется с песнями и плясками курсором, чтобы заюзать в своем запросе в качестве элемента; или я неправ ? Один из вариантов решения, предложенного в ASA: Код: plaintext 1. ASCRUS, я сколько читаю то что вы пишете про Sybase ASA, столько вам завидую белой завистью... потрясающий набор возможностей, безо всякой иронии говорю. С удовольствием бы под него попрограммировал :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:13 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
SergSuperНаверняка нечто подобное(последовательная обработка) приходится делать и на Оракле. Как это обычно делается? Где хранятся промежуточные результаты? Хм. Мой триггер остатков в этом не нуждался - впрочем, тут надо сравнивать структуры. Самое простое - запихнуть эти промежуточные результаты в nested table. Это тип данных, относящийся к "коллекциям" Оракла. Их удобство в том, что с ними можно работать как select-ами, так и обычным программным синтаксисом - доступ по индексу, изменение данных, удаление строки итп. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:14 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
softwarer[quot Alex.Czech]Если же имеется в виду постоянное применение, в "релизном программном коде" - надо пользоваться стандартными средствами, теми же GTT. Локальные средства здесь - прямой источник ошибок. Именно это. GTT не очень нравятся тем что при широком использовании этой фичи их будет очень много и они будут засорять взор при просмотре объектов БД. Тем, что их надо переносить на промышленную БД при переносе ХП. Впрочем, так себе объяснения, я согласен :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:15 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Oracle это тоже позволяет TABLE и PIPELINED. Кроме того всяческие игрища с bulk collect. Синтаксис конечно ужасный, но кто на это обращает внимание ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:16 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Alex.CzechИменно это. GTT не очень нравятся тем что при широком использовании этой фичи их будет очень много и они будут засорять взор при просмотре объектов БД. Тем, что их надо переносить на промышленную БД при переносе ХП. Впрочем, так себе объяснения, я согласен :) В Oracle GTT ОДНА на всех пользователей и на все сеансы, разделяются в ней данные. Так что ничего никому засорять не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:17 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
>> Так что ничего никому засорять не будет. Будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:20 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
SergSuper Во первых насколько я понял в Оракле нет возможности на AFTER TRIGGER получить весь набор измененных данных, а для позаписных триггеров времянки не нужны. Во вторых в Оракле помимо времянок существует еще куча различных структур данных (те же массивы), которые насколько я понял частенько бывают в нужных случаях эффективнее времянок. В третьих не забывайте, что у Оракла INSERT и UPDATE можно обьединить оператором MERGE (за название не ручаюсь), нарастающие спокойно реализуются аггрегатными запросами с использованием специальных OLAP и Windows функций, ну и т.д., т.п. В принципе у меня в ASA то же самое все и после перехода на нее с MSSQL мой код заметно ужался в 10-ки раз, использование времянок стало явлением нечастым (а с каждым ежемесячным паком и ростом уровня оптимизатора я что то помниться давно в коде времянок не обьявлял), по курсорам вообще придеться лезть в BOL и вспоминать как они там правильно обьявляются ... в общем понятно, что от того, что я получил более высокую функциональность, у меня сократилось время на написание кода и танцы с бубнами (этих тьфу тьфу вообще не наблюдается, пока на баги не наткнешься и то в основном танцуешь, чтобы обозначить баг и выслать его разработчикам). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:20 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Oracle это тоже позволяет TABLE и PIPELINED. Кроме того всяческие игрища с bulk collect. Синтаксис конечно ужасный, но кто на это обращает внимание ? Принципиально - позволяет. На практике а) Это уже процедуры, а не функции. Для тех кто скажет "who cares ?" я скажу, что не знаю до сих пор как из ADO получить результат выполнения PL/SQL-функции, не говоря уж о том что ADO не поддерживает параметры типа NESTED TABLE б) PIPELINED глючит, причем иногда ужасно... я лично имел пример PIPELINED-функции, которая при попытке использования в довольно извращенном виде (SELECT (SELECT * FROM t1 INNER JOIN fn(..) where t1.fid = t2.id) FROM t2) срубала коннекцию (ошибка TNS communication lost), после переписки того же на NESTED TABLE работает помедленнее, но зато ничего не срубает в) еще что-то было, пока писал первые 2 пункта, забыл третий :) При этом я хочу сказать, что не ставлю совершенно целью вывести утверждение "Оракл плохой". Оракл хороший, но кой-какие вещи и в нем делаются через жо, особенно когда надо поддержать кросс-плафторменность хотя бы в минимальном объеме (а нам тут надо) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:22 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Пункт а следует читать "это уже НЕ процедуры, а функции" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:23 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Что есть в Вашем понимании кроссплатформенность ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:24 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Что есть в Вашем понимании кроссплатформенность ? Наше ПО работает и на MS SQL, и на Оракл. При этом 90% "системного" кода и 99% прикладного одинаковые ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:29 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Честно говоря, не ощущаю в Oracle ПРИНЦИПИАЛЬНОЙ разницы между процедурами и функциями. Функции удобнее тем, что при определенных условиях их можно использовать в select, у процедур свои мелкие преимущества. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:30 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
softwarerСамое простое - запихнуть эти промежуточные результаты в nested table . Это тип данных, относящийся к "коллекциям" Оракла. Их удобство в том, что с ними можно работать как select-ами, так и обычным программным синтаксисом - доступ по индексу, изменение данных, удаление строки итп. Ну та же временная (или и переменная таблица в MS SQL) таблица получается. Вообще получается, что говорить о временных таблицах в разрезе их определения, данного в начале - нехорошо. Надо бы говорить о них в разрезе применения. А по применению получается, что везде они есть в явном или неявном виде -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:31 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Честно говоря, не ощущаю в Oracle ПРИНЦИПИАЛЬНОЙ разницы между процедурами и функциями. Функции удобнее тем, что при определенных условиях их можно использовать в select, у процедур свои мелкие преимущества. Я так подозреваю, что вы с ним не через ADO работаете :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:31 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Alex.CzechASCRUS, я сколько читаю то что вы пишете про Sybase ASA, столько вам завидую белой завистью... потрясающий набор возможностей, безо всякой иронии говорю. С удовольствием бы под него попрограммировал :) Я не буду точно утверждать, но по моему все что я пишу про ASA давно присутствует в IBM DB2 :) Такое чувство, что из за теплой дружбы iAnywhere и IBM (а как же иначе - ведь iAnywhere главный разработчик ПО под мобильные решения, четко ориентированные под связку с IBM продуктами) последняя разрешила движение WatcomSQL в свою сторону. Хотя вот недавно опрос проводился менеджерами ASA - в какую сторону совместимости впервую очередь нужно двигаться - MSSQL, Oracle или IBM DB2, большинство пользователей высказалось за Oracle, мотивируя это тем, что частенько ASA используется именно в связке с консолидированными хранилищами данных на Оракле. Хотя лично я не представляю, как это можно достигнуть большой совместимости между блокировочником и версионником - все равно способы написания кода будут существенно различаться, да и обычно на верхнем уровне и нижнем не требуется аналогичная функциональность - у каждого уровня свои задачи и своя реализация этих задач. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:33 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
А что, ADO селект из функции забракует? И даже с Оракловым провайдером? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:33 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Alex.Czech Gluk (Kazan)Что есть в Вашем понимании кроссплатформенность ? Наше ПО работает и на MS SQL, и на Оракл. При этом 90% "системного" кода и 99% прикладного одинаковые А наше на Unix-е и Windows, но мы здесь не этим мереемся Не верю я в Ваше понимание кроссплатформенности, тут я полностью солидарен с Кайтом. Хотя мне глубоко импонирует как DB2 может работать с гетерогенными БД. Насколько я понимаю, она подстраивается под особенности реализации других СУБД. Во всяком случае так я понял, прошу адептов сильно не пиннать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:34 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
www.fun4me.narod.ruА что, ADO селект из функции забракует? И даже с Оракловым провайдером? Гм. В принципе не забракует. Но тут уже пострадает та самая кросс-платформенность. Нужно еще учитывать, что первой была версия под MS SQL :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:35 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
tygraВообще получается, что говорить о временных таблицах в разрезе их определения, данного в начале - нехорошо. Надо бы говорить о них в разрезе применения. А по применению получается, что везде они есть в явном или неявном виде Это вопрос реализации. В Oracle больше возможностей для выбора и следовательно маневра при разработке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:36 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) Alex.Czech Gluk (Kazan)Что есть в Вашем понимании кроссплатформенность ? Наше ПО работает и на MS SQL, и на Оракл. При этом 90% "системного" кода и 99% прикладного одинаковые А наше на Unix-е и Windows, но мы здесь не этим мереемся Не верю я в Ваше понимание кроссплатформенности, тут я полностью солидарен с Кайтом. Хотя мне глубоко импонирует как DB2 может работать с гетерогенными БД. Насколько я понимаю, она подстраивается под особенности реализации других СУБД. Во всяком случае так я понял, прошу адептов сильно не пиннать. Это не мое понимание, это реальность данная нам в ощущениях. Если мы сегодня сделаем 2 проекта - один под MS SQL, другой под Оракл, оно наверняка заработает быстрее, но завтра мы все тут и подохнеми :) Хотя постепенно несомненно к этому дело идет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:37 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
авторГм. В принципе не забракует. Но тут уже пострадает та самая кросс-платформенность. Нужно еще учитывать, что первой была версия под MS SQL :) В принципе, преобразование вызова exec proc(...) в вызов select * from TABLE(proc(...)) - это достаточно простая операция. Можно автоматически сделать или IF поставить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:38 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Alex.Czech Это не мое понимание, это реальность данная нам в ощущениях. Если мы сегодня сделаем 2 проекта - один под MS SQL, другой под Оракл, оно наверняка заработает быстрее, но завтра мы все тут и подохнеми :) Хотя постепенно несомненно к этому дело идет Видите, Вы тоже согласны с Кайтом - должна быть прослойка инкапсулирующая платформенно-зависимые детали реализации :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:43 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) Alex.Czech Это не мое понимание, это реальность данная нам в ощущениях. Если мы сегодня сделаем 2 проекта - один под MS SQL, другой под Оракл, оно наверняка заработает быстрее, но завтра мы все тут и подохнеми :) Хотя постепенно несомненно к этому дело идет Видите, Вы тоже согласны с Кайтом - должна быть прослойка инкапсулирующая платформенно-зависимые детали реализации :) Разумеется. Ну так он и есть, но писать его как раз мне сотоварищи :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:46 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Потом появились переменные типа table и необходимость даже в локальных врем таблицах еще больше снизилась Недавно создавал для обсуждения такой топик в соседнем форуме по MSSQL. Лично мои эксперименты показали, что почему-то переменные типа table работают оч-ч-чень медленно по сравнению с врем таблицами. Не знаю почему ! Многократно проверялось на 100000 узких записей. Про курсоры (MSSQL): буквально вчера писал, что при умном использовании они могут дать огромный выигрыш. Даже пробегая по тысячам строк. Чесно говоря даже не думал, что эффект может быть таким сильным. :) PS: безусловно и тем и другим не стоит увлекаться. Но если по уму, то можно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 17:55 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Alex.CzechИменно это. GTT не очень нравятся тем что при широком использовании этой фичи их будет очень много и они будут засорять взор при просмотре объектов БД Вопрос в том, что они не менее важны, чем другие объекты БД. А "как правильно организовать большую кучу объектов" - сложный, но более или менее решаемый вопрос. Например, можно разнести по схемам. В моем любимом PL/SQL Developer есть удобно настраиваемые фильтры - то есть, я могу, например, легко убрать эти таблицы из общего списка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 18:17 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Alex.Czechскажу, что не знаю до сих пор как из ADO получить результат выполнения PL/SQL-функции, не говоря уж о том что ADO не поддерживает параметры типа NESTED TABLE У меня есть впечатление, что к Ораклу не стоит лазить через ADO (и кроссплатформенность тут не при чем). Но вне зависимости от этого - я совершенно уверен, что это возможно. Alex.Czechб) PIPELINED глючит, причем иногда ужасно... я лично имел пример PIPELINED-функции, которая при попытке использования в довольно извращенном виде (SELECT (SELECT * FROM t1 INNER JOIN fn(..) where t1.fid = Насчет "ужасно" - полагаю, некоторый перебор. Я помню одну ошибку, упомянутую на металинке - скорее всего, Ваш случай; сложный запрос и pipelined, получающая входные параметры из полей запроса. Alex.CzechОракл хороший, но кой-какие вещи и в нем делаются через жо, особенно когда надо поддержать кросс-плафторменность хотя бы в минимальном объеме (а нам тут надо) Хм. Тут уже был топик насчет "не нужно знать конкретную СУБД". Суть моего мнения - кроссплатформенность нужно делать, используя гибкие провайдеры и преимущества каждой из платформ. Пытаться использовать "технологии, которые работают везде" - например, использовать то же ADO для коннекта к любой из баз - сомнительный подход (допустимый, только если "действительно хорошо работает везде"). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 18:24 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
softwarer Alex.Czechб) PIPELINED глючит, причем иногда ужасно... я лично имел пример PIPELINED-функции, которая при попытке использования в довольно извращенном виде (SELECT (SELECT * FROM t1 INNER JOIN fn(..) where t1.fid = Насчет "ужасно" - полагаю, некоторый перебор. Я помню одну ошибку, упомянутую на металинке - скорее всего, Ваш случай; сложный запрос и pipelined, получающая входные параметры из полей запроса. Именно он и есть... и лично для меня когда от ошибки срубается коннекция и ее никак не обойти легким потряхиванием бубна - это ужасно :) Насчет ADO - теоретически я с вами согласен всеми руками. А практически когда весь огромный проект работает на ADO, взять и все переделать на некий "абстрактный гибкий провайдер" (да еще и такой, который будет работать лучше ADO, самого в некотором роде "абстрактного гибкого провайдера"), боюсь, нереально ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 18:27 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Alex.CzechНасчет ADO - теоретически я с вами согласен всеми руками. А практически когда весь огромный проект работает на ADO, взять и все переделать на некий "абстрактный гибкий провайдер" (да еще и такой, который будет работать лучше ADO, самого в некотором роде "абстрактного гибкого провайдера"), боюсь, нереально Хм. У меня нет практического опыта такого - но мне представляется, что затраты на "заставить Оракл и MSSQL одинаково работать" и на "сделать промежуточный уровень" вполне сравнимы при заведомо лучшем результате второго. Скажем, говоря о селекте - если это проблема, я бы сделал объект "выбиральщик из функции", который делает EXEC для MSSQL и select from table() для Oracle (либо использует ref cursor, либо еще как-нибудь). Перевести проект на использование такого объекта - тривиальная техническая операция, даже если инструмент потребует выполнить прорву тупой работы; а вот искать какое-то "общее решение" - порождает принципиальные проблемы и принципиальную же кривизну. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 18:38 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Alex.CzechИменно он и есть... и лично для меня когда от ошибки срубается коннекция и ее никак не обойти легким потряхиванием бубна - это ужасно :) Насколько я помню, для той ошибки есть патч. Впрочем - я согласен с тем, что от последних версий оракла хотелось бы большей устойчивости. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 18:39 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
softwarer Alex.CzechНасчет ADO - теоретически я с вами согласен всеми руками. А практически когда весь огромный проект работает на ADO, взять и все переделать на некий "абстрактный гибкий провайдер" (да еще и такой, который будет работать лучше ADO, самого в некотором роде "абстрактного гибкого провайдера"), боюсь, нереально Хм. У меня нет практического опыта такого - но мне представляется, что затраты на "заставить Оракл и MSSQL одинаково работать" и на "сделать промежуточный уровень" вполне сравнимы при заведомо лучшем результате второго. Скажем, говоря о селекте - если это проблема, я бы сделал объект "выбиральщик из функции", который делает EXEC для MSSQL и select from table() для Oracle (либо использует ref cursor, либо еще как-нибудь). Перевести проект на использование такого объекта - тривиальная техническая операция, даже если инструмент потребует выполнить прорву тупой работы; а вот искать какое-то "общее решение" - порождает принципиальные проблемы и принципиальную же кривизну. Да так и сделано в том, что касается селекта, разумеется... особо и вариантов-то других нету :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 18:40 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Alex.CzechДа так и сделано в том, что касается селекта, разумеется... особо и вариантов-то других нету :) Так это и есть начало того самого "гибкого провайдера". Повторить N раз - и окажется, что приложение работает на уровне собственных объектов. Разумеется, проектировать эти объекты тоже стоит с применением головы :) Вообще, собственные объекты - большой плюс. В дельфе вполне можно было не спешить с такой практикой, но перейдя на джаву, я довольно быстро начал любому стандартному классу тут же делать свою тривиальную обертку. Затраты - копеечные, зато потом все вскрывшиеся недостатки элементарно дорабатываются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 18:46 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
softwarer Alex.CzechДа так и сделано в том, что касается селекта, разумеется... особо и вариантов-то других нету :) Так это и есть начало того самого "гибкого провайдера". Повторить N раз - и окажется, что приложение работает на уровне собственных объектов. Разумеется, проектировать эти объекты тоже стоит с применением головы :) Вообще, собственные объекты - большой плюс. В дельфе вполне можно было не спешить с такой практикой, но перейдя на джаву, я довольно быстро начал любому стандартному классу тут же делать свою тривиальную обертку. Затраты - копеечные, зато потом все вскрывшиеся недостатки элементарно дорабатываются. Это уже не начало... это уже апофеоз :) Гибкий провайдер был гибким и когда еще с одной СУБД только умел работать. Проблема в том что невозможно написать сферический гибкий провайдер в вакууме и под первую СУБД всегда слегка подзатачиваешься, к сожалению... я повторюсь, что я не ставил целью сказать что Оракл плохой ни в коем случае, просто обрисовал для каких нужд в MS SQL используют временные таблицы, и сказал, что в Оракле аналогичного механизма нет. Может, он и не нужен никому, кроме меня... в принципе, он и мне уже не особо нужен :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 18:56 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
tygraНу та же временная (или и переменная таблица в MS SQL) таблица получается. Не совсем. Разница в том, что ее тип таки задается в правильном месте, а дальше употребляется локальный экземпляр этого типа. В MSSQL же, как я понимаю, используется что-то типа анонимных вложенных классов - на ходу определили и используем - но при этом этот объект еще и доступен снаружи (из других подпрограмм, с клиента) и этим пользуются. Имхо - это совершенно некорректно (хотя, конечно, можно и в такой системе придерживаться только корректных решений). Поэтому я изначально и сказал - то же самое по возможностям, но более корректная реализация. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 19:01 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
>> но при этом этот объект еще и доступен снаружи (из других подпрограмм, с клиента) и этим пользуются Недоступен локальный объект снаружи, чем и пользуются. :) Объект доступен только внутри, но не снаружи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 19:03 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Alex.Czechпросто обрисовал для каких нужд в MS SQL используют временные таблицы, и сказал, что в Оракле аналогичного механизма нет. Ээ.. Возможно, я не совсем понял, но мне показалось, что он таки есть - просто Вы испытываете некоторые проблемы с ADO (в котором, возможно, нет корректного решения для работы с оракловым механизмом). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 19:04 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
К сожалению, насколько мне известно, ADO наиболее прямой метод доступа в отношении MSSQL, но он далеко не так прям по отношению к Oracle ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 19:08 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
www.fun4me.narod.ruНедоступен локальный объект снаружи, чем и пользуются. :) Объект доступен только внутри, но не снаружи. Мне казалось, что временные таблицы в MSSQL - объекты сессионного уровня видимости. Я ошибался? А как тогда решается вопрос с их явной или неявной передачей между подпрограммами? В Оракле такую "совсем локальную" таблицу можно было бы делать видимой внутри пакета, но в MSSQL вроде бы пакетов нет. Соответственно - вопрос решается или приходится искусственно стягивать код в одну подпрограмму? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 19:09 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Таблицы созданные в сессии доступны на уровне сессии и во всех процедурах, которые вызываемы из сессии (вряд ли очень уж кому нужно), но при этом могут быть переопределены в процедурых, вызываемых из сессии. Таблицы, созданные в процедурах доступны только для процедуры и для всех процедур, вызываемых из данной процедуры (редко используется) и уничтожаются по завершении процедуры. То есть, там стэк из таблиц получается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 19:13 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
>>Таблицы .... Имелись ввиду временные #таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 19:14 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
www.fun4me.narod.ruТаблицы, созданные в процедурах доступны только для процедуры и для всех процедур, вызываемых из данной процедуры (редко используется) и уничтожаются по завершении процедуры. Понятно, спасибо. Не назову это решение хорошим, но остальные варианты еще хуже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 19:24 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Ну как же Вы можете об этом судить когда только что про это узнали? softwarer Самое простое - запихнуть эти промежуточные результаты в nested table. Это тип данных, относящийся к "коллекциям" Оракла. Их удобство в том, что с ними можно работать как select-ами, так и обычным программным синтаксисом - доступ по индексу, изменение данных, удаление строки итп. Можно чуть попобробней что такое nested table и как с ними можно работать? Хотелось бы примерчик какой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 10:00 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
авторПонятно, спасибо. Не назову это решение хорошим, но остальные варианты еще хуже. Тогда назовите отличия от Оракла - практически один в один получается. Только называется по-разному. Или заранее считается, что у MS все хуже? ;)) -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 11:12 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
действительно с временные таблицы в MSSQL и Sybase больше катят для хранения промежуточных выборок в процедурах. Но чтобы передавать выборки через временные таблицы тут нужно постараться. Компилить процедурку приходится таким образом - сначала создал временную табличку, потом откомпилил процедурку, грохнул табличку, создал вторую процедурку в которой создаешь врем. табличку и вызываешь первую процедурку. В принципе не сложно.. но все-же геморройно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 11:25 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
автордействительно с временные таблицы в MSSQL и Sybase больше катят для хранения промежуточных выборок в процедурах. Но чтобы передавать выборки через временные таблицы тут нужно постараться. Компилить процедурку приходится таким образом - сначала создал временную табличку, потом откомпилил процедурку, грохнул табличку, создал вторую процедурку в которой создаешь врем. табличку и вызываешь первую процедурку. В принципе не сложно.. но все-же геморройно. А теперь по-русски объясните, что вы там делаете, что компилите, как стараетесь .... При таком подходе естественно все будет геморройно . -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 11:31 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
tygra авторПонятно, спасибо. Не назову это решение хорошим, но остальные варианты еще хуже. Тогда назовите отличия от Оракла - практически один в один получается. Только называется по-разному. Или заранее считается, что у MS все хуже? ;)) -- Tygra's -- Отличия только в том, что у Оракла есть опции, определяющие, что делать с содержанием времянки на COMMIT - очищать ее или же сохранять записи. У ASA в 9-ке помимо этого еще ввели NOT TRANSACTIONAL, которое указывает, что времянке абсолютно почхать на транзакции и в не зависимости ROLLBACK/COMMIT записи в ней остаются в существующем состоянии. Это очень логично, особенно если учесть, что времянки в основном обьявляются в пределах какого то блока видимости, автоматом удаляются при выходе из этого блока и в основном не задействуются в транзакциях. Зато это дает существенный выигрыш в скорости работы DML с ними. Насколько я помню (хотя уже точно сказать не могу), у MSSQL времянки, обьявленные как DECLARE TABLE ведут себя фактически так же и поэтому обгоняют в скорости обычные времянки. Мне кажется тут гораздо интереснее сравнить не сколько функциональность времянок, а архитектуру их работы. У MSSQL времянки лежат в TempDB, которая фактически является полноценной БД. У ASA в понятии архитектуры база данных одна - то есть нет Master и TempDB - все пользователи, опции и права доступа находяться в самой БД, а промежуточная и временная информация храниться в временных файлах собственного формата в указанной для этих целей директории - собственный формат хранения (а не БД) такой информации кстати здорово увеличивает скорость работы с временными файлами, решает проблемы с блокировками при активном создании времянок множеством сессий и неполадками с TempDB, так как временные файлы ASA действительны только на время работы сервера и он к ним никак не привязывается. Интересно было бы послушать, как это организованно у Оракла и DB2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 11:39 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
tygra автордействительно с временные таблицы в MSSQL и Sybase больше катят для хранения промежуточных выборок в процедурах. Но чтобы передавать выборки через временные таблицы тут нужно постараться. Компилить процедурку приходится таким образом - сначала создал временную табличку, потом откомпилил процедурку, грохнул табличку, создал вторую процедурку в которой создаешь врем. табличку и вызываешь первую процедурку. В принципе не сложно.. но все-же геморройно. А теперь по-русски объясните, что вы там делаете, что компилите, как стараетесь .... При таком подходе естественно все будет геморройно . -- Tygra's -- Это судя по всему про Sybase ASE - там очень вумный компилятор не скомпилирует ХП, если в ней есть ссылки на несуществующие обьекты. Отсюда и такой большой бубен :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 11:41 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
2 ASCRUSS NOT LOGGED INITIALLY в DB2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 11:41 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
gardenman2 ASCRUSS NOT LOGGED INITIALLY в DB2 В общем судя по всему я так понимаю при желании мне перейти на IBM DB2 будет не очень долго :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 11:43 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
2 ASCRUS Понятно. 2 gardenman Но тогда на MS SQL не надо бочку катить, коли сведений нет. Он далеко уже от того Sybase ушел, на котором был сделан -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 11:43 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
tygraТогда назовите отличия от Оракла - практически один в один получается. Только называется по-разному. Отличия в следующем. Во-первых, nested table - это тип данных, регистрируемый на общих основаниях; это не "вложенный анонимный класс". Во-вторых, объекты типа nested table передаются как параметры. То есть не создается ситуация "таблица доступна в процедуре A, если она вызвана из процедуры B (где эта таблица создана), недоступна при вызове из процедуры C (где эта таблица не создана) и непонятно как доступна при вызове из процедуры D (где создается совершенно другая таблица, но с тем же именем, после чего вызывается A)". Ну и наконец, таки именно что возможность работать и так и этак - весьма удобная и вряд ли возможная для временных таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 13:04 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
SergSuperНу как же Вы можете об этом судить когда только что про это узнали? Я увидел проблему в решении, о котором мне рассказали, и спросил, как она решается. Это решение я могу (со своей колокольни, естественно), оценить, в том числе как "не назову хорошим". В то же время я не вижу возможности получить лучший результат в той же модели. SergSuperМожно чуть попобробней что такое nested table и как с ними можно работать? Хотелось бы примерчик какой Именно как тривиальный пример - например, здесь: /topic/146650&pg=2#1194010. Ну а описание и примеры - например, здесь . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 13:13 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
ASCRUSИнтересно было бы послушать, как это организованно у Оракла и DB2. У Oracle дело обстоит следующим образом. Коллекции (в частности, nested tables) - это объекты в памяти сервера, транзакционно-независимые. Как они свопятся - не разбирался, просто потому что никогда не требовалось загонять в них серьезные объемы данных. Global Temporary Tables реализованы так же, как и обычные таблицы, но с парой исключений: Если для обычной таблицы можно указать tablespace, в котором она размещается, то временные таблицы размещаются во временном tablespace, назначенном соответствующему пользователю. При работе с временными таблицами не генерируется ненужных временных данных, а потому операции с GTT заметно эффективнее использования постоянной таблицы в тех же целях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 13:58 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
softwarer ASCRUSИнтересно было бы послушать, как это организованно у Оракла и DB2. При работе с временными таблицами не генерируется ненужных временных данных, а потому операции с GTT заметно эффективнее использования постоянной таблицы в тех же целях. Саша, не возражаешь, если я немного уточню/добавлю: генерируется меньше данных redo (начиная с 9.2.0.5). Подробности здесь, например... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 14:09 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Vadim_MaximovСаша, не возражаешь, если я немного уточню/добавлю: генерируется меньше данных redo (начиная с 9.2.0.5). Нисколько не возражаю - я просто стараюсь отвечать, используя минимум незнакомых слов :) Что касается версии - я склонен верить Кайту, что в восьмерке то же самое. А поскольку с девяткой начал работать с 9.2.0.4 - на этот баг, видимо, не напарывался :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 14:16 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
В СУБД Teradata поддерживаются и локальные и глобальные временные таблицы. Локальные таблицы являются локальными внутри сессии, информация о них не прописывается в Data Dictionary. Место для них выделяется из временного пространства (SPOOL SPACE) пользователя, то есть из того, пространства, которое используется для хранения промежуточных итогов запросов. Синтаксис CREATE VOLATILE TABLE ... Соответственно, есть опция ON COMMIT PRESERVE/DELETE ROWS. Эти операции с такими таблицами можно логировать, а можно и нет. Они не выживают после рестарта системы. Ограничения - отсутствие постоянных журналов, механизмов ссылочной целостности, констрейнтов, сжатия столбцов, заголовков столбцов и именованных индексов. Определение глобальных временных таблиц хранится в Data Dictionary, они материализуются при первой операции с ними (как правило, это INSERT SELECT). Они также локальны к сессии. Место под них выделяется на основе установок TEMPORARY SPACE пользователя, создающего (материализующего) эти таблицы. Синтаксис CREATE GLOBAL TEMPORARY TABLE ... Также имеются опции ON COMMIT PRESERVE/DELETE ROWS и журналирования. Фактически, локальные от глобальных отличаются тем, что информация о последних хранится в каталоге, и то, что они могут пережить рестарт системы. Для чего нужны? Всё просто. Возьмём, например, такой инструмент, как Microstrategy. Это такая тулза, которая путём мышкования позволяет генерировать довльно сложный многопроходный SQL. При этом есть возможность использовать Derived Table или временные таблицы. Практика показывает, что некоторые отчёты выполняются быстрее, если используются Derived Table, а некоторые - если используются Temporary Table. Ну, и наконец, их счастье было бы неполным, если бы я здесь не привёл тот самый SQL. Итак: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. С уважением, Константин Лисянский http://lissianski.narod.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 15:19 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
DB2 временная таблица лежит в буфферном пуле. Если в нем нет места свопится в temporary tablespace. Temporary tablespace это или набор файлов внутри которых размазывается эта временная таблица или директория тогда каждая таблица это отдельный файл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 16:31 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
dimitr Один нюанс - MSSQL (и полагаю, что Sybase ASE также) разделяет данные GTT между сессиями. Никто больше этого не делает. Не разделяют они данные, ни тот, ни другой. В них видимость временных таблиц - сессия, поэтому данные разные сессии никак не могут разделать. Но у MSSQL есть еще таблицы с ## впереди - таблица видна всем сессиям, как и данные в ней (тоже всем сессиям). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 18:09 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
в Sybase ASE можно создать табличку tempdb..<TABLENAME> которая также как и ##TABLE будет доступна всем, но почистится после перезагрузки базы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 18:13 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Если оптимизатор в КОНКРЕТНОМ случае не справляется, это задача для тюнинга :) Существуют еще и АБСОЛЮТНО НЕОПТИМИЗИРУЕМЫЕ (сервером) ЗАПРОСЫ :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 18:14 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Не оптимизируемых (на уровне приложения) запросов НЕ СУЩЕСТВУЕТ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 18:36 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
MasterZiv dimitr Один нюанс - MSSQL (и полагаю, что Sybase ASE также) разделяет данные GTT между сессиями. Никто больше этого не делает. Не разделяют они данные, ни тот, ни другой. В них видимость временных таблиц - сессия, поэтому данные разные сессии никак не могут разделать. Но у MSSQL есть еще таблицы с ## впереди - таблица видна всем сессиям, как и данные в ней (тоже всем сессиям). Епрст. А я про что? Насколько я трезв, в MSSQL как раз оные ##-таблицы и есть ближайший аналог стандартных GTT. А #-таблицы - аналог LTT. Неужто я не прав? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 21:37 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
вобщем за исключением некоторых нюансов - всё едино, только название и синтаксис разный ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 11:23 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
SergSuperвобщем за исключением некоторых нюансов - всё едино, только название и синтаксис разный они тока кажутся похожими. Но на самом деле работать с ними приходится по разному. В MSSQL и Sybase ASE #-таблицы нужны шоб обойти ублюдочность ихнего SQL - диалекта. а GTT - это действительно временные данные на уровне сессии. сессия 1: create table ##TT (id int) The command(s) completed successfully. сессия 2: Server: Msg 2714, Level 16, State 6, Line 1 There is already an object named '##TT' in the database. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 11:44 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
авторВ MSSQL и Sybase ASE #-таблицы нужны шоб обойти ублюдочность ихнего SQL - диалекта А можно сразу комментарии. По ублюдочности. А то на предыдущий вопрос не ответили, может хоть тут. Может чего у вас с TSQL не так? -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 12:13 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
SergSuperвобщем за исключением некоторых нюансов - всё едино, только название и синтаксис разный Один из этих нюансов я упоминал в первом посте этого топика. Данные #-таблиц разделяются между сеансами. Но практическую пользу от этого я вижу смутно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 14:01 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
tygra авторВ MSSQL и Sybase ASE #-таблицы нужны шоб обойти ублюдочность ихнего SQL - диалекта А можно сразу комментарии. По ублюдочности. А то на предыдущий вопрос не ответили, может хоть тут. Может чего у вас с TSQL не так? Мне тоже интересно. Почти все высказавшиеся называли базовые причины использования временных таблиц, которые применимы ко всем серверам, пожалуй. Но тем не менее MSSQL-щики юзают их на порядок-другой чаще остальных. Это хорошо видно по мигрантам, задающим вопросы в топиках про Oracle/InterBase/etc. Так в чем же причина, собственно? В производительности ядра MSSQL? В недостаточности языковых воможностей для сложных запросов? В менталитете разработчиков? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 14:07 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
dimitrМне тоже интересно. Почти все высказавшиеся называли базовые причины использования временных таблиц, которые применимы ко всем серверам, пожалуй. Но тем не менее MSSQL-щики юзают их на порядок-другой чаще остальных. Это хорошо видно по мигрантам, задающим вопросы в топиках про Oracle/InterBase/etc. Так в чем же причина, собственно? В производительности ядра MSSQL? В недостаточности языковых воможностей для сложных запросов? В менталитете разработчиков? Лично мое мнение - что в недостатке возможностей для сложных запросов. Производительность ядра у MSSQL очень даже на уровне и он имеет довольно мощный и современный оптимизатор даже на текущий момент, несмотря на то, что был сделан в 2000 году. Ну и еще плюс не стоит забывать про архитектуру блокировочника и исторически сложившуюся архитектуру в частности самого MSSQL. Здесь тоже времянки иногда помогают выйти из положения. Ну а менталитет разработчиков - хорошие пользуются времянками, когда это получается заведомо выгоднее и эффективнее, плохие - потому как просто не знают, не думают как можно по другому (это тоже самое, как и использование курсоров). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 14:14 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
когда в MSSQL ьщжно будет писать вот так как тут в конце страницы тогда можно будет стравнивать MSSQL c Oracle или DB2, а иначе - веь этот треп - просто проявление комплекса неполноценности... Можно даже подвести под МSSQL некую логичскую черту: 1) CTE - нет 2) Рекурсивных запросов -нет 3) триггеров before/for each row нет 4) SQUENCE - нет 5) timestamp - вообще непонятно что 6) тип данных DATE - отсутствует как класс (и TIME тоже) 7) структурные типы - отсутствуют... 8) а где многоплатформенность? 9) а как на счет масштабируемости и кластеров? а сравним PL/SQL с T-SQL? а попробуйте написать на ESQL/C++ ХП, так как это можно делать в DB2? И вы хотите сравнивать это все с Оracle или DB2 ?... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 14:31 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
ах да...)) GTT - от микрософт - это не GTT ...)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 14:32 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
В Юконе как раз можно будет так писать, как в конце той страницы. Получается, что уже можно сравнивать - бета есть :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 14:42 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
gardenman, позиция "против" - она, вобщем-то, выражаясь вашим языком, ублюдочная под MS SQL работает довольно большой процент серверов, но вы не пытаетесь понять почему, вы просто пытаетесь доказать что M$ хуже во всём. Зачем Вам это? Инфантилизм какой-то а 5-й пункт - просто убивает наповал. Действительно зачем нужен такой сервер если gardenman не понимает что такое timestamp? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 14:49 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Там очень много чего в конце страницы. Тем более чего там относится к временным таблицам я так и не понял..... автор2) Рекурсивных запросов -нет Уже показали, что и без них нет проблем автор3) триггеров before/for each row нет Без них неплохо. автор4) SQUENCE - нет А зачем? автор5) timestamp - вообще непонятно что Ну кому что и как :) автор6) тип данных DATE - отсутствует как класс (и TIME тоже) Ну есть datetime, ничего,хватает автор7) структурные типы - отсутствуют... А зачем? автор8) а где многоплатформенность? А не нужна автор9) а как на счет масштабируемости и кластеров? Вот это единственное, чего жаль что нет автора сравним PL/SQL с T-SQL? а попробуйте написать на ESQL/C++ ХП, так как это можно делать в DB2? Ничего, работаем авторИ вы хотите сравнивать это все с Оracle или DB2 ?... Мы не хотим, мы уже. И работаем однако. И хорошо работаем. И не выдумываем различных причин. И все неплохо получается. И насильно никому не навязываем - аллергию на MS пока не лечат -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 14:50 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Снимаю шляпу перед tygra... более убедительно еще никто не показывал мне как я неправ... Публично приношу извинения всем тем, кто любит MS SQL.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 14:53 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Не менее убедительно, чем gardenman Так бы и давно -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 14:55 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
tygra автор2) Рекурсивных запросов -нетУже показали, что и без них нет проблем автор3) триггеров before/for each row нетБез них неплохо. автор4) SQUENCE - нетА зачем? автор5) timestamp - вообще непонятно чтоНу кому что и как :) автор6) тип данных DATE - отсутствует как класс (и TIME тоже) Ну есть datetime, ничего,хватает автор7) структурные типы - отсутствуют...А зачем? автор8) а где многоплатформенность?А не нужна автор9) а как на счет масштабируемости и кластеров?Вот это единственное, чего жаль что нет автора сравним PL/SQL с T-SQL? а попробуйте написать на ESQL/C++ ХП, так как это можно делать в DB2?Ничего, работаем авторИ вы хотите сравнивать это все с Оracle или DB2 ?... Мы не хотим, мы уже. И работаем однако. И хорошо работаем. И не выдумываем различных причин. И все неплохо получается. И насильно никому не навязываем - аллергию на MS пока не лечатСкипнуть нечего - рука не понимается, очень напоминает ответы людей, работающих с IB\FB, всем остальным ;) Разве что про аллергию нет - это специфика MS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 15:05 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
tygra автор3) триггеров before/for each row нет Без них неплохо. Хм. Тут в соседнем форуме ACSRUS высказался в том духе, что тривиальные манипуляции - типа "держать данные в поле заглавными буквами" - без них нормально не делаются. Прокомментируете? tygra автор4) SQUENCE - нет А зачем? Удобно. Собственно, MS уже ответил на вопрос "зачем", внедряя GUID. tygra автор7) структурные типы - отсутствуют... А зачем? Удобно. По тем же причинам, по которым они удобны, например, в ЯВУ. tygra автор8) а где многоплатформенность? А не нужна Сложный вопрос. С точки зрения маркетинга это минус - достаточно много народу скажет "у нас уже есть платформа X, вот и будем покупать то, что с ней работает". Хотя понятно, что многоплатформенность в MSSQL если и будет, то на уровне "WinNT либо .NET". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 15:06 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
авторВ Юконе как раз можно будет так писать, как в конце той страницы. Получается, что уже можно сравнивать - бета есть :) Сам Юкон не видел, но на вскидку там будут: CTE, Recursive, Date, Time, C# ... есть ли что еще из списка фич других СУБД ? Насколько помню: не будет триггеров BEFORE и EACH ROW, если что поправьте. Возникает еще вопрос многостродальной теме C# в MSSQL - он там будет только как язык ХП использоваться или же на C# можно делать классы, которые обьявлять как домены и хранить их экземпляры в таблицах ? Типа как в ASA (берем кусок BOL): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 15:08 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Фишка вот в чем. Все перечисленные мной опции есть в других базах уже несколько лет. К тому времени, когда у других появится еще что-то, MS реализует те, которых у нее нет сейчас. Таким образом получается что MSSQL - ситематически оказывается в роли аутсайдера в области разработки БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 15:12 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 15:17 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
авторХм. Тут в соседнем форуме ACSRUS высказался в том духе, что тривиальные манипуляции - типа "держать данные в поле заглавными буквами" - без них нормально не делаются. Прокомментируете? Дык есть другие триггеры. After insert, например. А по триггеру for each row я тоже горевал, когда давно еще с IB пришел. А ничего теперь, как-то привык да и нет больше нужды. :) авторУдобно. Собственно, MS уже ответил на вопрос "зачем", внедряя GUID. Это как GUID может быть ответом на SQUENCE? Что-то не пойму. Выше кстати было сказано, что отличается SQUENCE от Identity на 95%. А Гуид вообще из другой песни. авторУдобно. По тем же причинам, по которым они удобны, например, в ЯВУ. Зато хуже разбираться с системой. авторСложный вопрос. С точки зрения маркетинга это минус - достаточно много народу скажет "у нас уже есть платформа X, вот и будем покупать то, что с ней работает". Хотя понятно, что многоплатформенность в MSSQL если и будет, то на уровне "WinNT либо .NET". Ну хозяин барин. Кто чего хочет, тот то и покупает. По мне так правильно, что нет кроссплатформенности. Продукты от одного производителя. Зачем лезть куда-то еще, если ты наоборот продвигаешь свою ОС? Это нехорошо как-то получилось бы :)) -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 15:17 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
авторФишка вот в чем. Все перечисленные мной опции есть в других базах уже несколько лет. К тому времени, когда у других появится еще что-то, MS реализует те, которых у нее нет сейчас. Таким образом получается что MSSQL - ситематически оказывается в роли аутсайдера в области разработки БД. Ну если вы определяете возможности СУБД по вашему списку опций, то для вас вывод правильный. Однако многие другие работают с MS SQL и чувствуют себя нормально, а некоторые даже и хорошо. Впрочем не лучше и не хуже, чем остальные. Если же вы что-то не можете сделать руками - только опции подавай - то тогда да, оставайтесь на Оракле. Если вы на нем, конечно. А для остальных аутсайдер весьма неплохо работает. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 15:22 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
ASCRUS авторВ Юконе как раз можно будет так писать, как в конце той страницы. Получается, что уже можно сравнивать - бета есть :) Сам Юкон не видел, но на вскидку там будут: CTE, Recursive, Date, Time, C# ... есть ли что еще из списка фич других СУБД ? Ага. Я просто заленился все это писать :) Возникает еще вопрос многостродальной теме C# в MSSQL - он там будет только как язык ХП использоваться или же на C# можно делать классы, которые обьявлять как домены и хранить их экземпляры в таблицах ? Второе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 15:24 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
ASCRUS авторВ Юконе как раз можно будет так писать, как в конце той страницы. Получается, что уже можно сравнивать - бета есть :) Сам Юкон не видел, но на вскидку там будут: CTE, Recursive, Date, Time, C# ... есть ли что еще из списка фич других СУБД?да, все это это будет. Одна из самых интересных, на мой взгляд, возможностей это версионность на уровне строк. ASCRUSНасколько помню: не будет триггеров BEFORE и EACH ROW, если что поправьте.вы абсолютно правы, этого пока не будет. ASCRUSВозникает еще вопрос многостродальной теме C# в MSSQL - он там будет только как язык ХП использоваться или же на C# можно делать классы, которые обьявлять как домены и хранить их экземпляры в таблицах ?С помощью .Net языков можно будет создавать SP, UDF, UDT, триггеры и пользовательские агрегаты. Посмотрите ссылку на презентацию, там вся реализация описана по шагам. gardenmanФишка вот в чем. Все перечисленные мной опции есть в других базах уже несколько лет. К тому времени, когда у других появится еще что-то, MS реализует те, которых у нее нет сейчас. Таким образом получается что MSSQL - ситематически оказывается в роли аутсайдера в области разработки БД.MS идет своим путем, попутно беря все лучшее что есть у остальных СУБД на сегодняшний день. Посмотрите хотя бы на список компонент, которые будут представлять собой MS SQL 2005. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 15:24 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
>MS идет своим путем, попутно беря все лучшее что есть у остальных СУБД на сегодняшний день. Посмотрите хотя бы на список компонент, которые будут представлять собой MS SQL 2005. боюсь мы уже тут смотрели этот список и не нашли ничего чего бы небыло в oracle8i, а на дворе 2005 год ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 15:28 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
ну значит не туда смотрели. Возьмите хотя бы интеграцию с .Net Framework и как она оценивается даже теми людьми, документ которых вы приводили как весомое доказательство превосходства Oracle над MS SQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 15:37 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
вы хотите сказать что попытка МС создать свою джаву удалась МС лучше чем оригиналу ? согласитесь спорно ... ;) еще есть преимущества переде 8i ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 15:47 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
tygraДык есть другие триггеры. After insert, например. А по триггеру for each row я тоже горевал, когда давно еще с IB пришел. А ничего теперь, как-то привык да и нет больше нужды. :) after-то есть - но ценой удвоения работы сервера. Плюс неочевидный момент рекурсии при таком обновлении. tygra авторУдобно. Собственно, MS уже ответил на вопрос "зачем", внедряя GUID. Это как GUID может быть ответом на SQUENCE? Что-то не пойму. Выше кстати было сказано, что отличается SQUENCE от Identity на 95%. А Гуид вообще из другой песни. Хм. Sequence отличается от Identity очень простым образом - уж простите, не понял, что есть "выше". Sequence - это объект, с которым как хочешь, так и работаешь. А identity - это нечто вроде атрибута поля и "ни шага влево, ни шага вправо". По крайней мере, если опять же ничего не изменилось по сравнению с версиями, о которых мне рассказывали. Guid же, насколько я понимаю, является "ответом на sequence" потому что позволяет MSSQL нормально реплицироваться - чего (насколько я в курсе) не умеет identity. tygra авторУдобно. По тем же причинам, по которым они удобны, например, в ЯВУ. Зато хуже разбираться с системой. Не понял смысла этой фразы. Хм. Допустим, в бейсике не было почти ничего - и поэтому для описания объекта с тремя атрибутами приходилось завести переменные A, B$ и B1$ (имена тоже допускались - буква или буква-цифра). Потом стало возможно таки писать record, struct или аналогичные конструкции. Стало хуже разбираться с системой? Не понял. Поясните, пожалуйста, может быть на примере - что Вы имеете в виду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 15:49 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
2 Yo!: хм.. как-то вы с темы на тему перескакиваете. По поводу того документа и оценки в нем интеграции .Net и MS SQL вы согласны или нет? Если да, то вопрос решен, если нет, это означает что вы не со всем в нем согласны, тогда зачем вы его вообще советовали смотреть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 15:58 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
авторХм. Sequence отличается от Identity очень простым образом - уж простите, не понял, что есть "выше". Sequence - это объект, с которым как хочешь, так и работаешь. А identity - это нечто вроде атрибута поля и "ни шага влево, ни шага вправо". По крайней мере, если опять же ничего не изменилось по сравнению с версиями, о которых мне рассказывали. Guid же, насколько я понимаю, является "ответом на sequence" потому что позволяет MSSQL нормально реплицироваться - чего (насколько я в курсе) не умеет identity. Ну секвенс то аналог identity вообще-то. А гуид - это просто другой тип данных. Какая связь? Ну а репликация - а как тут секвенс связан с ней? -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 16:01 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
tygra авторХм. Sequence отличается от Identity очень простым образом - уж простите, не понял, что есть "выше". Sequence - это объект, с которым как хочешь, так и работаешь. А identity - это нечто вроде атрибута поля и "ни шага влево, ни шага вправо". По крайней мере, если опять же ничего не изменилось по сравнению с версиями, о которых мне рассказывали. Guid же, насколько я понимаю, является "ответом на sequence" потому что позволяет MSSQL нормально реплицироваться - чего (насколько я в курсе) не умеет identity. Ну секвенс то аналог identity вообще-то. А гуид - это просто другой тип данных. Какая связь? Ну а репликация - а как тут секвенс связан с ней? -- Tygra's -- Гм, возможно аналогу секвенса в ASA служит Global Autoincrement - который ведется непрерывно для всей БД, но в пределах, заданных в опции "Database ID". В итоге все работают каждый в пределах своего промежутка значений, в консолидированной БД не возникает конфликтов PK, однако в самой консолидированной БД счетчик под ее DataBase id не сбивается при подливе данных с других СУБД и все вставляемые записи опять же работают в собственном промежутке, таким образом избегая обратных конфликтов. Все это работает автоматом, единственное где могут быть траблы при репликации - это при сбивании кода БД или же ввода одинаковых, однако это уже на совести проектировщика. Конечно самое надежное конечно это GUID - тут вообще никаких конфликтов быть просто не может, хотя если сравнивать bigint и GUID - немного разные размеры типов данных получаются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 16:13 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
авторхм.. как-то вы с темы на тему перескакиваете. По поводу того документа и оценки в нем интеграции .Net и MS SQL вы согласны или нет? Если да, то вопрос решен, если нет, это означает что вы не со всем в нем согласны, тогда зачем вы его вообще советовали смотреть? советовал смотреть чтоб вы вообще представляли в чем есть отличия, этот документ наиболее полно их перечисляет, а со мнением естественно я согласен не со всем. например про .net и java я не согласен - мне все равно через врапер или нет запускается моя java, главное чтоб потери в скорости небыло. когда появятся тесты тогда и можно поговорить о преимуществах прямого запуска, а так это просто слова (если не углублятся в сами языки и их конструкции). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 16:27 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
tygraНу секвенс то аналог identity вообще-то. identity - это частный случай применения sequence. В общем случае, использование монотонных последовательностей не ограничивается unique-столбцами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 16:27 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
tygraНу секвенс то аналог identity вообще-то. А можно поподробнее? Насколько я видел, identity - это атрибут поля, а секвенсор - это объект. То есть если мне нужно обеспечить сквозную нумерацию по нескольким таблицам, секвенсор легко решает эту задачу, а с identity придется извращаться (делать отдельную таблицу, на которую ссылаться?!). tygraА гуид - это просто другой тип данных. Какая связь? Ну а репликация - а как тут секвенс связан с ней? Хм. Связь следующая: насколько я понимаю, в MSSQL поставить default SYS_GUID (или нечто аналогичное - миль пардон за синтаксис) - это наиболее простой путь обеспечить нормальную репликацию. Другой путь - здесь, на sql.ru, лежит статья http://www.sql.ru/articles/mssql/03100902ArchitectingReplicationWithIdentityColumns.shtml, из которой получается, что MSSQL2000 таки дает какую-то особую опцию для управления диапазонами, в результате чего можно построить репликацию на основе identity и довольно кривой схемы распределения номеров. Осталось сравнить это с Код: plaintext И - никаких вопросов. Собственно, меня несколько удивляет, почему в MSSQL нельзя сделать такого же - но, полагаю, у автора статьи, размещенной на столь компетентном сервере, были какие-то причины :) Ну и так все-таки - насчет "хуже разбираться" поясните? А то как-то странно получается - уже второй раз в этой теме я говорю что-то, а Вы замолкаете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 16:34 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Start value и seed value у IDENTITY безусловно настраиваются... так что имхо для репликации никаких проблем я не вижу. Вот когда нужно одно ID на несколько таблиц сразу автоинкрементить - это и есть те самые 5% (о которых я говорил в другом топике), где identity проигрывает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 16:37 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
А вообще прискорбно, что все это вылилось в очередную религиозную войну. "Нет, не об этом он мечтал всю свою сознательную жизнь" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 16:40 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Блин... чтобы узнать Identity-значение нужно обядательно вставить строку в таблицу. (сделать транзакцию) Последнее значение возвратится в @@identity. Чтобы получить значение из последовательности - нужно сделать запрос, который находится все транзакции. Разница - ОГРОМНА! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 16:45 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Alex.CzechStart value и seed value у IDENTITY безусловно настраиваются... так что имхо для репликации никаких проблем я не вижу. Я - со своей ламерской колокольни - тоже не вижу и удивляюсь. Но предположительно солидный автор на уважаемом сервере зачем-то предлагает куда более сложную и неудобную схему. Вы готовы поручиться своей репутацией, что это только из-за того, что он нерюх и идиот? Напишите Джуджу, что эту статью стоит выбросить и не позориться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 16:48 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Alex.CzechStart value и seed value у IDENTITY безусловно настраиваются... так что имхо для репликации никаких проблем я не вижу. Вот когда нужно одно ID на несколько таблиц сразу автоинкрементить - это и есть те самые 5% (о которых я говорил в другом топике), где identity проигрывает Ради интереса - настраиваться то понятно настраивается. А вот не сбивается ли, если с других БД приходят записи с заведомо более высоким диапазоном номеров ? То есть работает у нас Identity в пределах 1-100 и равен 2, приходит с другой БД запись 101. Какой следующий номер будет присвоен при вставке новой записи в этой таблице ? По идее он должен равняться 3-ем. авторА вообще прискорбно, что все это вылилось в очередную религиозную войну. "Нет, не об этом он мечтал всю свою сознательную жизнь" Да нет - даже ссылочки интересные по Юкону привели, с удовольствием почитал, как там и чего будет выглядеть в целях самообразования. Есть правда один неутешительный вывод - формула "ПО от MS = Геммор" к сожалению продолжает успешно работать и они где нибудь, да обязательно сделают пару недоработок/ошибок, которые потом придется дружно обходить. авторБлин... чтобы узнать Identity-значение нужно обядательно вставить строку в таблицу. (сделать транзакцию) Последнее значение возвратится в @@identity. Чтобы получить значение из последовательности - нужно сделать запрос, который находится все транзакции. Разница - ОГРОМНА! Давненько Вы с MSSQL не работали :) Уже давно есть куча функций, которая позволяет вне транзакции без вставки записи узнавать для указанных таблиц текущий и следующий Increment. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 16:48 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
ASCRUS Alex.CzechStart value и seed value у IDENTITY безусловно настраиваются... так что имхо для репликации никаких проблем я не вижу. Вот когда нужно одно ID на несколько таблиц сразу автоинкрементить - это и есть те самые 5% (о которых я говорил в другом топике), где identity проигрывает Ради интереса - настраиваться то понятно настраивается. А вот не сбивается ли, если с других БД приходят записи с заведомо более высоким диапазоном номеров ? То есть работает у нас Identity в пределах 1-100 и равен 2, приходит с другой БД запись 101. Какой следующий номер будет присвоен при вставке новой записи в этой таблице ? По идее он должен равняться 3-ем. Сбивается, согласен. Не подумал об этом. Все равно репликацию на GUID-ах делал всегда, когда делал... точнее, в таблице делалось 2 ключа - int identity и плюс еще guid только для репликации ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 16:51 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Ну вот мы и нашли оправдание существования большой статьи :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 16:54 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
gardenmanБлин... чтобы узнать Identity-значение нужно обядательно вставить строку в таблицу. (сделать транзакцию) Последнее значение возвратится в @@identity. Чтобы получить значение из последовательности - нужно сделать запрос, который находится все транзакции. Разница - ОГРОМНА! Огромна для MSSQL. Это уже глобальная тема, на которую нынче принято отвечать "а вот в юконе все будет хорошо". Другой вопрос, что развязывание по времени этих двух событий само по себе может оказаться удобным, если идет какая-нибудь сложная схема со взаимодействием нескольких процессов - мне, правда, такого делать не приходилось. Другой аспект - секвенсоры позволяют легко и довольно эффективно получить массив будущих id-шников, в то время как @@identity вряд ли столь универсальна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 16:55 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
а всегда ли будет @@identity=IDENT_CURRENT('table_name')+1 после добавления? и, каким образом мне сдвинуть значение identity? или зарезервировать какой-то промежуток значений для своей транзнакции? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 16:59 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
авторРади интереса - настраиваться то понятно настраивается. А вот не сбивается ли, если с других БД приходят записи с заведомо более высоким диапазоном номеров ? То есть работает у нас Identity в пределах 1-100 и равен 2, приходит с другой БД запись 101. Какой следующий номер будет присвоен при вставке новой записи в этой таблице ? По идее он должен равняться 3-ем. а разве у автоинкремента не так-же если я прямо пишу 101 то и запишется 101 а не 3 ? ЗЫ. в оракле номер берут из сиквенса в тригери а не из другой субд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 17:03 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Alex.CzechСбивается, согласен. Не подумал об этом. Все равно репликацию на GUID-ах делал всегда, когда делал... точнее, в таблице делалось 2 ключа - int identity и плюс еще guid только для репликации Хм. Согласитесь, эти две задачи удобнее решать одним полем :) P.S. Не продумал про сбивание. Слишком зашорен - привык, что "текущее значение" хранится и явно запрашивается-изменяется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 17:03 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
softwarer Alex.CzechСбивается, согласен. Не подумал об этом. Все равно репликацию на GUID-ах делал всегда, когда делал... точнее, в таблице делалось 2 ключа - int identity и плюс еще guid только для репликации Хм. Согласитесь, эти две задачи удобнее решать одним полем :) P.S. Не продумал про сбивание. Слишком зашорен - привык, что "текущее значение" хранится и явно запрашивается-изменяется. Соглашусь, конечно... в принципе можно решать и одним полем - типа GUID - если записей немного, иначе производительность падает. Но вообще мне самому идея identity не очень нравится, если честно, sequence несомненно лучше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 17:06 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Yo! авторхм.. как-то вы с темы на тему перескакиваете. По поводу того документа и оценки в нем интеграции .Net и MS SQL вы согласны или нет? Если да, то вопрос решен, если нет, это означает что вы не со всем в нем согласны, тогда зачем вы его вообще советовали смотреть?советовал смотреть чтоб вы вообще представляли в чем есть отличия..знаете, в отличие от некоторых (не будем показывать пальцем) прежде чем говорить про то что плохо в другой СУБД, я стараюсь в ней разобраться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 17:12 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Yo!например про .net и java я не согласен - мне все равно через врапер или нет запускается моя java, главное чтоб потери в скорости небыло. когда появятся тесты тогда и можно поговорить о преимуществах прямого запуска, а так это просто слова (если не углублятся в сами языки и их конструкции).почему же просто слова? есть целый ряд статей, в которых написано в каких случаях .NET будет работать быстрее TSQL и наоборот. Они приводились на примере beta2, но тем не менее, даже на этой, совсем не оптимальной по производительности версии сервера .Net показывает себя очень даже неплохо и оправдывает свое присутствие в сервере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 17:28 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
segunпочему же просто слова? есть целый ряд статей, в которых написано в каких случаях .NET будет работать быстрее TSQL и наоборот. Они приводились на примере beta2, но тем не менее, даже на этой, совсем не оптимальной по производительности версии сервера .Net показывает себя очень даже неплохо и оправдывает свое присутствие в сервере. статьи на всьяпупкин.народ.ру действительно бывают очень интересными, может дадите линк где бы не поламерски организовали тестирование ? только не на словах и пальцах, а нормальные тесты которые я бы мог повторить ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 17:33 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
2 softwarer Про хуже разбираться не скажу - передумал :)) По секвенсам/идентити. Да, когда нужно обеспечить уникальность счетчика на несколько таблиц одновременно или обеспечить вставку данных с бОльшими значениями, то тут identity хреново подходит, только если через дополнительную таблицу. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 17:46 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
2 Yo!: вообще-то в статьях как правило код, который при желании можно повторить и проанализировать. Но что-то говорит мне что вы, уважаемый, все равно не станете это делать. У вас есть SQL2k5 beta2? У вас стоит хотя бы SQL2k? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 17:47 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
автора всегда ли будет @@identity=IDENT_CURRENT('table_name')+1 после добавления? Всегда, если никто не успел добавить до того, как вы узнали IDENT_CURRENT('table_name') автори, каким образом мне сдвинуть значение identity? или зарезервировать какой-то промежуток значений для своей транзнакции? Ну измените текущее значение идентити, а то. что себе оставили, добавляйте с set identity_insert on Хотя я не припомню задач, где бы ID было нужно заранее, а тем более уж сразу несколько заразервировать. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 17:50 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
авторвообще-то в статьях как правило код, который при желании можно повторить и проанализировать. Но что-то говорит мне что вы, уважаемый, все равно не станете это делать. У вас есть SQL2k5 beta2? У вас стоит хотя бы SQL2k? ну покажите же наконец эту чудо статью, я заинтригован. я так понимаю я там увижу java код для оракла и аналогичный на .Net для юкона и соответствено замеры скорости ? и там же я так понимаю и увижу то самое превосходство ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 18:03 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
tygra Хотя я не припомню задач, где бы ID было нужно заранее, а тем более уж сразу несколько заразервировать Например при копировании ветки дерева ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 18:17 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
tygraХотя я не припомню задач, где бы ID было нужно заранее, а тем более уж сразу несколько заразервировать. Массовая загрузка данных. Запрос id - довольно дорогая операция, поскольку требует синхронизации на высшем уровне. Соответственно, если сервер занят не только загрузкой, запрашивать по одному номеру на каждую запись - довольно неэффективно. Полагаю, это справедливо для всех серверов - то есть, я не вижу способа избежать этой проблемы. Ну а масштабы - видны на достаточно простом примере (на пустом сервере). Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 18:23 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
1. SEQUENCE it's cool :), но он не решает проблем с репликацией по большому счету, так как в базе-источнике и базе-приемнике свои значения упомянутого, которые могут также пересекатся, как и identity. Для репликации в идеале надо получать идентификаторы, практически гарантировано, уникальные вне зависимости от сервера, базы и таблицы. Этим требованиям до определенной степени удовлетворяет GUID, но никак не sequence в чистом виде, который по смыслу представляет обычный identity, но в масштабе всей БД, а не отдельной таблицы. 2. Кстати, до стандарта SQL2003 ни о каких SEQUENCE речи не идет, правда, не идет речи и об identity :) , это к тому, что MS SQL пытается не сильно отрыватся от базовых стандартов, что не всегда получается, ровно, как и у всех остальных, разве что Sybase ASA, и то по отрывочным слухам. Здесь можно поверить ACRUS, если он подтвердит, хотя по некоторым примерам, которые он приводил, тоже есть тенденция расширять стандарты ради удобства. Собственно это к тому, что многие возможности выходят за рамки стандарта и производители часто реализуют их по своему. И лучше это или хуже, IMHO, судить сложно. В частности, мне ни разу не приходилось сталкиваться с потребностью создавать сквозную нумерацию через несколько "разношерстных" таблиц за достаточно немалый срок работы с СУБД, и она кажется несколько "искусственной". Если таковая возможность требовалась, то обычно это было связано с тем, что таковые таблицы по смыслу были подчиненными и связаными с "главной" таблицей, в которой и было поле identity, значения которого мигрировали в ключ "подчиненных" таблиц. 3. Если в некоторых случаях был необходим признак, гарантировано уникальный и монотонно возрастающий в пределах БД, например, для отслеживания порядка создания записей из разных таблиц, для этого в MS SQL достаточно использовать тип timestamp, который не имеет ровно никакого отношения ко времени, а представляет тупо и монотонно возрастающее binary(8) значение. У него есть один "минус", оно изменяется при каждом обновлении строки, так как в некотором смысле представляет собой версию строки, и поэтому является его же "плюсом". При необходимости "помнить" первоначальное значение полученное при вставке, его можно сохранить в другом поле типа binary(8), триггером при вставке, например. Это ни плохо, ни хорошо, это так. 4. Потребность получить заранее значение типа autoincrement, до реальной вставки в таблицу, чтобы затем его использовать, может привести с одной стороны к тому, что разные пользователи могут получить одно и то же значение, что в дальнейшем может привести к конфликту при вставке. С другой стороны, если после каждого чтения значения такого счетчика оно инкрементируется, то возникает опасность быстрого "исчерпания" в случае неверного кодирования, например при "зацикливании". Опять же, если необходимо получить диапазон идентификаторов типа identity, то никто не мешает получить последнее вставленное значение, а затем "сдвинуть" его на нужный шаг, зная, что "пропущенный" промежуток можно использовать позже, но это на любителя и при острой необходимости. P.S. Sorry за многословность, в этом виноваты стакан водки и коньяка :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 02:24 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
softwarer Guid же, насколько я понимаю, является "ответом на sequence" потому что позволяет MSSQL нормально реплицироваться - чего (насколько я в курсе) не умеет identity. вот сижу и думаю, как это у меня работает репликация на identity с разделением диапазонов по серверам? ведь не должна, а работает.... наверное мне только кажется, что у меня mssql, а реально там крутится oracle. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 05:59 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
ASCRUS Ради интереса - настраиваться то понятно настраивается. А вот не сбивается ли, если с других БД приходят записи с заведомо более высоким диапазоном номеров ? То есть работает у нас Identity в пределах 1-100 и равен 2, приходит с другой БД запись 101. Какой следующий номер будет присвоен при вставке новой записи в этой таблице ? По идее он должен равняться 3-ем. если пришел по репликации - и будет равняться 3. куда он денется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 06:05 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Возвращаясь к первоначальной теме... dimitr какие выводы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 11:10 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
А выводы обязательно должны быть? ;-) По общим методам использования TT тут много интересного сказали, и почти все это хорошо коррелируется с моим собственным опытом. Насчет чрезмерной любви сиквелистов к TT я, пожалуй, соглашусь с выводами ASCRUS'а, ибо внятных доказательств обратного мы так и не услышали. Все еще более-менее спорной остается необходимость в CLTT... А так, в целом, неплохо поговорили... хотя без флейма все равно не обошлось ;-))) К слову, какие дополнительные атрибуты CLTT и DLTT поддерживают сервера? Я имею ввиду констрейнты, индексы, триггеры. Имеет ли практический смысл вообще иметь триггеры для DLTT? Или те же FK? И еще один нюанс - я так понимаю, что опции DELETE/PRESERVE ROWS для DLTT особого смысла не имеют? Или все же множество транзакций внутри ХП является общепринятой практикой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 11:34 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
dimitrА выводы обязательно должны быть? ;-) Если это будет в FB 2.0, то просто интересно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 11:59 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
ChA1. SEQUENCE it's cool :), но он не решает проблем с репликацией по большому счету, так как в базе-источнике и базе-приемнике свои значения упомянутого, которые могут также пересекатся, как и identity. Решает. Я даже написал, как именно. После этого пересечься они могут только в результате "действий руками" - ну а тут и GUID не спасет. ChA Для репликации в идеале надо получать идентификаторы, практически гарантировано, уникальные вне зависимости от сервера, базы и таблицы. Совершенно излишние требования. Вы просто подгоняете требования к тому, что есть в MSSQL. ChA 2. Кстати, до стандарта SQL2003 ни о каких SEQUENCE речи не идет, правда, не идет речи и об identity :) , это к тому, что MS SQL пытается Хм. Если бы сервера не отрывались от стандартов - мы бы их сейчас ругали совсем не за детали репликации :) ChAВ частности, мне ни разу не приходилось сталкиваться с потребностью создавать сквозную нумерацию через несколько "разношерстных" таблиц за достаточно немалый срок работы с СУБД, и она кажется несколько "искусственной". Если таковая возможность требовалась, то обычно это было связано с тем, что таковые таблицы по смыслу были подчиненными и связаными с "главной" таблицей, в которой и было поле identity, значения которого мигрировали в ключ "подчиненных" таблиц. Вы другими словами сказали то же самое - вводить искусственную таблицу с identity. Просто представьте себе, что "главная" таблица не содержит ничего, кроме этого id - ну и, быть может, еще пары атрибутов, типа "создатель" и "дата создания", ради которых не стоит городить таблицу. Что касается примера - пожалуй, самый "горячий" будет связан с популярным желанием сделать таблички физ-юр лиц со сквозными id - дабы "одним полем id адресовать обе таблицы". Я здесь не имею в виду поднимать тему "насколько это хорошо"; просто наиболее навязшее в зубах. ChA3. Если в некоторых случаях был необходим признак, гарантировано уникальный и монотонно возрастающий в пределах БД, например, для отслеживания порядка создания записей из разных таблиц, для этого в MS SQL достаточно использовать тип timestamp, который не имеет ровно никакого отношения ко времени, а представляет тупо и монотонно возрастающее binary(8) Согласен, это вполне удобный для репликации id. По крайней мере пока не пойдет вопрос переполнения :) ChAЭто ни плохо, ни хорошо, это так. Хм. А прокомментируете то, что я уже упоминал - если я правильно понимаю, такие манипуляции на триггерах связаны с необходимостью второй раз update-ить ту же запись (и соответственно с дополнительной нагрузкой). ChA4. Потребность получить заранее значение типа autoincrement, до реальной вставки в таблицу, чтобы затем его использовать, может привести с одной стороны к тому, что разные пользователи могут получить одно и то же значение, что в дальнейшем может привести к конфликту при вставке. Не может. Наличие такой вероятности автоматом свидетельствует об одной из двух крайне неприятных вещей: либо о возможности получить то же непосредственно при вставке, либо о жесткой синхронизации каждой вставки в таблицу - и тогда о больших базах можно забыть. ChAС другой стороны, если после каждого чтения значения такого счетчика оно инкрементируется, то возникает опасность быстрого "исчерпания" в случае неверного кодирования, например при "зацикливании". Хм. В случае неверного кодирования можно получить абсолютно любые результаты - даже верные, если повезет. Не понимаю, что следует из этого аргумента. Реально "теряется" весьма немного id-шников, и, полагаю, если бы они вычислялись при вставке, терялись бы настолько же часто - поскольку основной причиной потери является rollback. ChAОпять же, если необходимо получить диапазон идентификаторов типа identity, то никто не мешает получить последнее вставленное значение, а затем "сдвинуть" его на нужный шаг, зная, что "пропущенный" промежуток можно использовать позже, но это на любителя и при острой необходимости. Эта проблема, к сожалению, нормально решается только в Interbase - правда, там свои минусы. Тем не менее, возможность получить id до вставки весьма актуальна - в качестве простого примера можно назвать работу с мастер-деталью с клиента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 12:01 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
andy stвот сижу и думаю, как это у меня работает репликация на identity с разделением диапазонов по серверам? ведь не должна, а работает.... наверное мне только кажется, что у меня mssql, а реально там крутится oracle. ;) Думаю, реально у Вас крутится решения наподобие предложенного в упомянутой мной статье. Это решение кажется мне.. неоправданно сложным и неудобным - например, с моей точки зрения, диапазоны id вообще не слишком удачная идея. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 12:03 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Dik76Если это будет в FB 2.0, то просто интересно :) Не надо делать из FB2 всеобщего счастья. Что будет - то будет, остальное - потом. Мне до пенсии еще далеко ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 12:06 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
dimitr Dik76Если это будет в FB 2.0, то просто интересно :) Не надо делать из FB2 всеобщего счастья. Что будет - то будет, остальное - потом. Мне до пенсии еще далеко ;-)Да мне собственно TT и не нужны, мне ХП хватает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 12:29 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
softwarer Думаю, реально у Вас крутится решения наподобие предложенного в упомянутой мной статье. Это решение кажется мне.. неоправданно сложным и неудобным - например, с моей точки зрения, диапазоны id вообще не слишком удачная идея. идея та. но сложности ни какой не наблюдается. серверу один раз сказали размер окна для разделения диапазонов, а остальное делает он сам. в т.ч. и выделение нового при превышении существующего. работает неплохо, и сразу видно, с какой базы ноги у записей растут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 12:34 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
andy stработает неплохо, и сразу видно, с какой базы ноги у записей растут. Хм. Не понимаю, как "сразу видно" откуда растут ноги у записей - имхо, при выделении диапазонов для этого приходится выполнять запрос. Другой момент - диапазонный механизм требует поддержки со стороны сервера (совершенно лишний код, который только усложняет дело) и вызывает вопрос переговоров участников репликации о выделении очередных диапазонов - грубо говоря, если сервер оказывается надолго отрезан от связи, могут быть проблемы. Можете на примере - может быть, я неправильно Вас понял? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 14:04 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
когда говорят что реплякация работает хорошо по с ключом по диапазонам - это значит врут. Врут и не краснеют. Работа с диапазонами записей никогда не была удобна. Составной ключ - так или иначе все к нему приходят или начинают эмулировать. Именно отсутствие секвенсов приводит к этому геморрою. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 14:19 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
softwarer Хм. Не понимаю, как "сразу видно" откуда растут ноги у записей - имхо, при выделении диапазонов для этого приходится выполнять запрос. Другой момент - диапазонный механизм требует поддержки со стороны сервера (совершенно лишний код, который только усложняет дело) и вызывает вопрос переговоров участников репликации о выделении очередных диапазонов - грубо говоря, если сервер оказывается надолго отрезан от связи, могут быть проблемы. Можете на примере - может быть, я неправильно Вас понял? несколько серверов... несколько рабочих мест... один публикатор, остальные подписчики, репликация транзакциями. результат действий оператора пишется в таблицу событий (запись = поля описания события + поля с identity). рабочее место может прицепиться к любому из серверов. для каждого сервера задан свой диапазон identity для этой таблицы. т.е. на подписчике 1 - 999999, на втором сервере 1000000 - 1999999 и т.п. (т.е. так определяются "откуда растут ноги у записей"). никаких заморчек со стороны клиента - просто insert в таблицу на нужном сервера - запись придет ко всем с identity из дапазона сервера. на сервере - при создании репликации 1 раз был указан размер диапазона и % его заполнения для выделения нового диапазона. собственно ВСЕ. по поводу надолго отрезан - прецедентов пока не было. но диапазон выбирался из расчета работы диапазона примерно года на 3-4. за такое время линию связи уж точно восстановят. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 14:25 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
gardenmanкогда говорят что реплякация работает хорошо по с ключом по диапазонам - это значит врут. Врут и не краснеют. Работа с диапазонами записей никогда не была удобна. Составной ключ - так или иначе все к нему приходят или начинают эмулировать. Именно отсутствие секвенсов приводит к этому геморрою. если у кого-то она работает хорошо, а у кого-то плохо, то стоит задуматься:либо первые врут, либо у вторых кривые руки или кривой софт. первое (я вру) исключается ввиду того, что я наблюдаю работающую без вмешательства систему. на счет второго выбирайте сами ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 14:34 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
softwarerпока не пойдет вопрос переполнения :)Хммм... Переполнение при 2 64 ? Теоретически - да, а если реально смотреть на жизнь ? softwarerА прокомментируете то, что я уже упоминал - если я правильно понимаю, такие манипуляции на триггерах связаны с необходимостью второй раз update-ить ту же запись (и соответственно с дополнительной нагрузкой)Нет, контекст потерял :) По поводу обновления, не нужно оно на практике, так как запоминать первоначальное значение timestamp при вставке бессмысленно. Суть timestamp не в том, чтобы дать уникальный идентификатор в пределах БД, а в указании последовательности операций модификации данных, что и может применяться при некоторых видах репликации. softwarerВы другими словами сказали то же самое - вводить искусственную таблицу с identityЗдесь не могу с Вами согласится, не таблица это искуственная, а решение, при котором разные таблицы пользуют один SEQUENCE. Смысл в чем ? Если это разные сущности, то зачем они разделяют одну и ту же последовательность ? Пусть каждая имеет свою. Если же сущность одна, но с подтипами(подкатегориями), то она должна иметь свою таблицу, чтобы подчиненные таблицы могли использовать ссылочное ограничение. На примере Ю и Ф лиц: если по бизнес-логике в БД может существовать таблица, в которой определенное поле может ссылатся на обе таблицы, то сделать ссылочное ограничение на обе таблицы одновременно все равно нельзя, так зачем огород в виде разделяемой последовательности городить ? Чтобы отлавливать кодом эту ссылочную целостность ? Конечно, можно идти и таким путем, но, IMHO, это потеря "прозрачности", связи подобного рода между данными должны быть прописаны явно, а не хранится где-то в дебрях кода. softwarerВы просто подгоняете требования к тому, что есть в MSSQLНикак нет, насколько помню для каких-то видов репликации, кажется MERGE, именно это и нужно, но так как не использую, то не готов защищать эту точку зрения. P.S. Не пытаюсь защитить MS SQL или противопоставить его Oracle, все что хотелось бы сказать: одни и те же задачи можно решать разными способами, и сравнение в однозначное превосходство одного из них далеко не всегда оправдано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 14:47 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
есть консолидированная база, где у каждого филиала - свой диапазон. Попробуйте-ка баланс представить в разрезе филиалов, или баланс по нескольким. А если таких отчетов несколько? И потом с этим мудохаться все время пока живет система? В гробу я видел такое проектирование...((( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 14:47 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
а добавление нового филиала? выделение нового диапазона?... и не лень вам? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 14:50 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
вообще, когда 1 поле содержит информацию по 2 понятиям (код филиала, + код документа), дорогие мои, это пахнет нарушением 1НФ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 14:54 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
andy stодин публикатор, остальные подписчики, Честно говоря, уже неинтересно :) andy stдля каждого сервера задан свой диапазон identity для этой таблицы. т.е. на подписчике 1 - 999999, на втором сервере 1000000 - 1999999 и т.п. (т.е. так определяются "откуда растут ноги у записей"). И? Как только автоматически выделится следующий диапазон - откуда Вы узнаете, какому серверу он принадлежит? Или будете помнить, что "первый миллион - первый сервер, второй - второй, третий миллион - снова второй, четвертый миллион - первый, пятый миллион - третий..." И так, я полагаю, помнить по каждой таблице? У меня их, знаете ли, реплицировалось порядка тысячи двухсот; память кончится. andy st по поводу надолго отрезан - прецедентов пока не было. но диапазон выбирался из расчета работы диапазона примерно года на 3-4. за такое время линию связи уж точно восстановят. ;) Хм. Знаете, возможности сервера на таких объемах как-то неловко обсуждать :) Полагаю, с миллионом записей за три-четыре года и парадокс справится без особых проблем. А вот через четыре года - давайте Вы нам расскажете, так ли удобно определять, "откуда ноги растут". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 14:57 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
gardenmanесть консолидированная база, где у каждого филиала - свой диапазон. Попробуйте-ка баланс представить в разрезе филиалов, или баланс по нескольким. А если таких отчетов несколько? И потом с этим мудохаться все время пока живет система? В гробу я видел такое проектирование...((( конкретно в чем проблема. баланс составится в разрезе и филиалов и отделов филиалов. диапазоны тут причем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 14:59 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
gardenmanа добавление нового филиала? выделение нового диапазона?... и не лень вам? дык публикатор сам и даст ему диапазон. мое участие - только добавить подписчика. а уж без этого ну никак нового филиала не добавить... ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 15:01 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
gardenmanвообще, когда 1 поле содержит информацию по 2 понятиям (код филиала, + код документа), дорогие мои, это пахнет нарушением 1НФ! и что дальше? пойдем спорить по поводу целесообразности того, надо ли всегда придерживаться 1НФ или нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 15:03 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
ага, и еще нужно будет подправить десяток-другой отчетов, или написать функцию, которая бы делала из id-поля номер филиала, и сделать чтобы это все работало быстро.... У меня как-то заниматься этими глупостями нет особого желания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 15:03 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
softwarer И? Как только автоматически выделится следующий диапазон - откуда Вы узнаете, какому серверу он принадлежит? Или будете помнить, что "первый миллион - первый сервер, второй - второй, третий миллион - снова второй, четвертый миллион - первый, пятый миллион - третий..." И так, я полагаю, помнить по каждой таблице? У меня их, знаете ли, реплицировалось порядка тысячи двухсот; память кончится. а я помнить и не буду. мне это надо, чтобы в реальном времени разруливать проблемы, не более. а потом - совершенно начхать на диапазоны. это еще к части по поводу "через 4 года" softwarer Хм. Знаете, возможности сервера на таких объемах как-то неловко обсуждать :) Полагаю, с миллионом записей за три-четыре года и парадокс справится без особых проблем. ;) давайте еще пиписьками померяемся. я же не сказал, какие размеры остальных таблиц, а уже такие предположения стоятся... обалдеть, фантазеры... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 15:13 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
gardenmanага, и еще нужно будет подправить десяток-другой отчетов, или написать функцию, которая бы делала из id-поля номер филиала, и сделать чтобы это все работало быстро.... У меня как-то заниматься этими глупостями нет особого желания. зачем делать из id номер филиала? сами себе проблему придумали, сами отказываемся ее решать... просто зашибись... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 15:15 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
ChA softwarerпока не пойдет вопрос переполнения :)Хммм... Переполнение при 2 64 ? Теоретически - да, а если реально смотреть на жизнь ? Там не зря стоит смайлик. Но если учесть, что у меня ожидаемый прирост базы порядка 2^32 записей в год - для "пересчета по каждому чиху" число не кажется таким уж фантастическим. ChAПо поводу обновления, не нужно оно на практике, так как запоминать первоначальное значение timestamp при вставке бессмысленно. Суть timestamp не в том, чтобы дать уникальный идентификатор в пределах БД, а в указании последовательности операций модификации данных, что и может применяться при некоторых видах репликации. Стоп. Я понимаю этот вариант, но говорю о другом. С моей точки зрения, крайней удобно делать id записи "подходящим для репликации". Подобный timestamp - если его можно накрутить до нужного старта - подошел бы для этого (для небольших/прогнозируемых баз). Без этого же - это просто данные, которые вряд ли могут понадобиться иначе чем в целях администрирования. ChAСмысл в чем ? Если это разные сущности, то зачем они разделяют одну и ту же последовательность ? Пусть каждая имеет свою. Смысл в том, что последовательности могут применяться не только для суррогатных ключей, но и для нумерации документов. И бухгалтер вполне может сказать - и говорит на практике - "хочу, чтобы все типы накладных имели сквозную нумерацию". Поскольку это несложно сделать - разумно пойти ему навстречу. Ну а то, что "все накладные" запросто могут не иметь предка - исключая разве что "самого общего" - полагаю, очевидно. ChAНа примере Ю и Ф лиц: если по бизнес-логике в БД может существовать таблица, в которой определенное поле может ссылатся на обе таблицы, то сделать ссылочное ограничение на обе таблицы одновременно все равно нельзя, так зачем огород в виде разделяемой последовательности городить ? Огород в виде разделяемой последовательности позволяет не делать поля наподобие "тип записи, на которую ссылается данное поле". Пример звучал здесь же совсем недавно - CONTRACTORS JOIN PHPERSONS дает всех контрагентов-физиков, CONTRACTORS JOIN ORGS дает всех контрагентов-юриков. Лично мне такой подход не нравится. Но он существует, достаточно часто упоминается и, собственно, при многочисленных категориях адресатов становится менее невыгодным, чем другие варианты. ChA softwarerВы просто подгоняете требования к тому, что есть в MSSQLНикак нет, насколько помню для каких-то видов репликации, кажется MERGE, именно это и нужно, но так как не использую, то не готов защищать эту точку зрения. Сказать по правде, я не знаю, что такое MERGE репликация, но почти уверен, что это термин откуда-то из MSSQL. Во всяком случае, адекватная репликация спокойно делается при куда более слабых требованиях. ChA P.S. Не пытаюсь защитить MS SQL или противопоставить его Oracle, все что хотелось бы сказать: одни и те же задачи можно решать разными способами, и сравнение в однозначное превосходство одного из них далеко не всегда оправдано. Можно решать разными способами. Если Вы посмотрите подборку моих писем - я не склонен кричать "лучше всегда и везде". Собственно, когда мне говорят "а вот здесь не лучше" - я даже чаще верю на слово, нежели лезу проверять. Что касается секвенсоров - они с одной стороны не имеют явных собственных недостатков, а с другой позволяют "одним движением" решить задачи, каждую из которых можно решать большими или меньшими усилиями "другими методами". То есть: да, можно раздать диапазоны. И на небольших базах это сработает. Да, можно не забыть при создании каждого поля добавлять "not for replication" - хотя это уже плохое, неудобное требование. Можно сделать GUID и плевать на его большой размер. Но вопрос: зачем? То, что позволяет одной строкой обойтись без всего этого, по-моему, таки "лучше". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 15:18 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
andy stа я помнить и не буду. мне это надо, чтобы в реальном времени разруливать проблемы, не более. Допустим - хотя уже весьма сомнительно. Итак, для скольких таблиц и скольких серверов Вы обещаете помнить текущие диапазоны? andy st;) давайте еще пиписьками померяемся. Зачем? Вы сначала сказали - у Вас работает, а потом оказывается, что работает в совершенно нерепрезентативных условиях. То есть - я совершенно уверен, что MSSQL способен на куда большее. Соответственно, Ваше утверждение становится примерно таким: MSSQL крут, поскольку приемлимо решает копеечную задачу. Лично у меня о нем лучшее мнение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 15:21 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
softwarerТам не зря стоит смайлик. Но если учесть, что у меня ожидаемый прирост базы порядка 2^32 записей в год - для "пересчета по каждому чиху" число не кажется таким уж фантастическим.Смайлик может иметь совершенно разный смысл, который не всегда понятен из контекста, от "уничтожающего" сарказма до извинительной улыбки ;) Да, пожалуй на 2 32 лет может и не хватить :) softwarerСмысл в том, что последовательности могут применяться не только для суррогатных ключей, но и для нумерации документов. И бухгалтер вполне может сказать - и говорит на практике - "хочу, чтобы все типы накладных имели сквозную нумерацию".Не надо говорить о том, кто и чего захочет и к этому приплетать метод решения гипотетических проблем. Схема БД строится не исходя из пожеланий левой ноги бухгалтера, а из анализа сущностей предметной области и связей между ними. Если нужна сквозная нумерация документов, то это значит, что эти документы представляют собой одну и ту же сущность, но с подтипами, а значит у них должна быть master-таблица. Можно захотеть сделать сквозную нумерациую и через все документы, если таковы исходные требования, но это значит, что все документы воспринимаются как экземпляры одной и той же сущности, или класса, если угодно. В таковом случае, в master-таблице будут "жить" те свойства документов, которые присутствуют и имеют один и тот же смысл для всех документов. Вопрос в правильном подходе к проектированию БД, а не "склеивании" разнородных сущностей путем использования последовательностей. Полагаю, что это тоже очевидно :) softwarerЛично мне такой подход не нравится.И совершенно правильно не нравится, так как в некотором смысле это тоже нарушение 1НФ, когда в значении идентификатора "незримо" присутствует тип записи. Возможно, страдаю идеализмом, но, IMHO, проектирование БД определяется не "выгодностью" того или иного конкретного решения, а большим или меньшим соответствием реляционной модели данных. авторЧто касается секвенсоров - они с одной стороны не имеют явных собственных недостатков, а с другой позволяют "одним движением" решить задачи, каждую из которых можно решать большими или меньшими усилиями "другими методами".И снова соглашусь с Вами, больше методов, хороших и разных :) Но только они должны быть оправданы спецификой задач, а не потому, что проектирование сделано из рук вон... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 16:19 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
softwarer andy stа я помнить и не буду. мне это надо, чтобы в реальном времени разруливать проблемы, не более. Допустим - хотя уже весьма сомнительно. Итак, для скольких таблиц и скольких серверов Вы обещаете помнить текущие диапазоны? есть такая фича в mssql, как Код: plaintext ;) softwarer andy st;) давайте еще пиписьками померяемся. Зачем? Вы сначала сказали - у Вас работает, а потом оказывается, что работает в совершенно нерепрезентативных условиях. То есть - я совершенно уверен, что MSSQL способен на куда большее. я прекрасно знаю, что mssql способен на горазо большее - крутятся задачки и посерьезнее (с точки зрения логики, объемов данных, кол-ва пользователей). но в описанном мной примере того, что сделано хватает за глаза. softwarer Соответственно, Ваше утверждение становится примерно таким: MSSQL крут, поскольку приемлимо решает копеечную задачу. Лично у меня о нем лучшее мнение. ну епрст... а чем определяется "копеечность" задачи? для меня, например, на первом месте идет логика системы, а не ее размеры (в некоторых случаях юзаем многогигабайтовые базы с видеорядом, на крайняк я в базу могу десяток-другой iso-шек залить для объема). количество таблиц тоже не всегда показатель (сделать сотню join совершенно не в напряг). если у вас на первом месте объемы - стоит еще поработать.... через годик-два посмотрим... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 06:08 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
слушайте тут соседи рассказали о странных тормозах mssql и каких-то системных блокировках ... решили вместе поискать что это могло бы быть и нашли: http://www.sql-server-performance.com/temp_tables.asp SQL Server Temp Table Performance Tuning Tips Generally speaking, temp tables should be avoided , if possible. They are created in the tempdb database and create additional overhead for SQL Server, slowing overall performance. As an alternative to temp tables, consider the following alternatives: * Rewrite your code so that the action you need completed can be done using a standard query or stored procedure, without using a temp table. а ведь меня почти залечили, что #tmp удобней :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 17:16 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Yo!! пишет: > слушайте тут соседи рассказали о странных тормозах mssql и каких-то > системных блокировках ... решили вместе поискать что это могло бы быть > и нашли: (пропущено) > а ведь меня почти залечили, что #tmp удобней :) Это проблемы MSSQL, а не временных таблиц вообще. Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 17:23 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
>Это проблемы MSSQL, а не временных таблиц вообще. не ну понятно что проблемы сиквела, причем я не понимаю зачем что-то курочить в системных таблицах если видеть надо в предимость одной сесии. а у ASA/ASE таких проблем нет ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 17:38 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Yo!! пишет: >>Это проблемы MSSQL, а не временных таблиц вообще. > > не ну понятно что проблемы сиквела, причем я не понимаю зачем что-то > курочить в системных таблицах если видеть надо в предимость одной сесии. > > а у ASA/ASE таких проблем нет ? На счет ASE не в курсе. А вот в ASA временные таблицы - очень мощный и удобный инструмент, проблем по скорости не встречал и уж тем более рекомендаций неиспользования. Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 18:02 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Yo!!>Это проблемы MSSQL, а не временных таблиц вообще. не ну понятно что проблемы сиквела, причем я не понимаю зачем что-то курочить в системных таблицах если видеть надо в предимость одной сесии. а у ASA/ASE таких проблем нет ? У ASA нет и быть не может в силу ее архитектуры (даже отсутствуют такие понятия, как MasterDB, TempDB и вообще времянки хранятся во временном файле, который создает сервер на время своей работы, который как я подозреваю является аналогом механизма write-file для read-only БД). У ASE скорее всего есть хотя бы потому, что MSSQL писался с нее и ее архитектура,в том числе TempDB надо думать не сильно отличается от архитектуры MSSQL. Кстати у ASA например GLOBAL TEMPORARY TABLE ни коем образом не имеет ничего схожего с ##GlobalTempTable в MSSQL, а являются обычными времянками с предопределенной в БД структуре (видны даже из Enterprise), автоматически создаются для каждой подключаемой сессии, где каждая сессия будет иметь свой набор данных в таких таблицах. Соотвествующе и в глобальных времянках здесь никто никогда никого не блокирует и не тормозит, так как физически во время работы сессии работают с разными таблицами, которые будут автоматически удалены по окончании работы сессии. А вот то, что локальные и глобальные времянки можно делать как NOT TRANSACTIONAL прибавляет скорости работы с ними и соотвествующе дает больше поводов сложные части запросов по мере надобности выводить во времянки, чтобы не сводить оптимизатор с ума, а так же снижать время блокировок на высшем уровне изоляции во время длинных транзакций, что тоже согласитесь приятно для тех, кто работает с блокировочниками :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2005, 18:57 |
|
||
|
О временных таблицах замолвите слово...
|
|||
|---|---|---|---|
|
#18+
Yo!!слушайте тут соседи рассказали о странных тормозах mssql и каких-то системных блокировках ... решили вместе поискать что это могло бы быть и нашли: http://www.sql-server-performance.com/temp_tables.asp SQL Server Temp Table Performance Tuning Tips Generally speaking, temp tables should be avoided , if possible. They are created in the tempdb database and create additional overhead for SQL Server, slowing overall performance. As an alternative to temp tables, consider the following alternatives: * Rewrite your code so that the action you need completed can be done using a standard query or stored procedure, without using a temp table. а ведь меня почти залечили, что #tmp удобней :)Советую обратить внимание на слова "Generally speaking". Так оно и есть, временные таблицы лучше не использовать если можно обойтись без них. Но, бывают случаи, когда при явном разделении большого запроса с джоинами к многомиллионным таблицам, можно существенно повысить производительность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2005, 14:28 |
|
||
|
|

start [/forum/topic.php?all=1&fid=35&tid=1553899]: |
0ms |
get settings: |
11ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
27ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
166ms |
get tp. blocked users: |
2ms |
| others: | 255ms |
| total: | 491ms |

| 0 / 0 |
