Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8   вперед  Ctrl      все
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
ChA
Посему позвольте просто процитировать некоторые выдержки из книги "Inside Microsoft SQL Server 2000"

Спасибо, интересно. Перед продолжением основной темы было бы интересно узнать еще одну важную деталь: как именно синхронизируются передача данных клиенту с работой продолжающей гнать данные ХП? Кто и что делает в момент, когда единственный выходной буфер заполнен?

ChA
Опять момент, когда я перестаю Вас понимать.

Давайте напомню. Этот фрагмент беседы пошел с фразы о том, что если процедура возвращает ref cursor, этот рекордсет может быть использован как клиентом, так и другой серверной ХП, в то время как в MSSQL придется выбирать - то ли "неявный рекордсет", который может быть принят клиентом, то ли курсор, который можно передать в другую ХП. Вы предложили возвращать временную таблицу, которая доступна и так, и эдак. Я постулировал то, что обсуждаем выше - дополнительные накладные расходы. И вот здесь появилась мысль насчет разбивок и ситуаций, когда разбивка приводит к повышению эффективности. Так вот, по-моему это уже не имеет особого отношения к изначально заданной теме о двойном использовании, о чем я и говорю.

Что касается вытеснения временной таблицы на диск - оно понятно. Я не упоминаю этот вариант из-за контекста "накладных расходов" - если временная таблица вытесняется на диск перед возвратом клиенту, это уже большие дополнительные расходы по сравнению с "неявным рекордсетом", лишние чтение-запись. Поэтому для сравнения я сосредоточился на варианте, где таких расходов нет, выборка остается целиком в ОЗУ.

ChA
Не надо придавать временной таблице никакого мистического смысла

Дык никто и не придает.

ChA
Могу только повторить, это, IMHO, несколько иная тема.

Несколько иная. Я об этом говорю только как объяснение того, почему я не то чтобы полностью согласен с Вашей аргументацией о полезности разбиения.

ChA
Так в этом и состояла моя цель, нефиг ему гадать, я лучше знаю, как здесь поступить и готов платить за это, в том числе, потерей "прозрачности" кода и беря на себя ответственность за последствия.

Я знаком с такой позицией и могу повторить то, с чего начал: я сомневаюсь в оптимальности такого подхода. Я с некоторыми ограничениями верю в Вашу способность придумать наилучший план в данных текущих условиях, но я абсолютно уверен, что в ходе эксплуатации ИС оптимальный план одного и того же запроса меняется, и "я лучше знаю" становится тормозом.

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

ChA
Возможно в Oracle оптимизатор никогда не принимает неверных решений.

Принимает. Но программисты, считающие себя умнее оптимизатора, принимают такие решения гораздо чаще. Поэтому я однозначно за "мягкие" решения.

ChA
Ни то, и ни другое. Именно рекурсивная пользовательская фильтрация. ...

Не готов оценить "удобство реализации на клиенте". Мне кажется, в этом случае:

1. Необходима механика уборки мусора
2. Необходимо всюду пихать "and session_id = :my_session_id"
3. Накладные расходы на отношение к временной по сути таблице как к постоянной

Здесь я предполагаю, что механизм длинной транзакции с итоговым rollback-ом неприменим - поправьте, если я ошибаюсь.
21 ноя 06, 12:50    [3429105]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
softwarer, Вы несколько категоричны в суждениях (насчет временных таблиц(ВТ))
Я прекрасно понимаю чего хочет сказать ChA и у меня создаётся такое ощущение что Вы всеми силами пытаетесь объяснить ему что он делает неправильно. Надеюсь мы не будем похожи на упёртых кашистов если я скажу что надо везде учитывать свою специфику.

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

Для примера приведу свой триггер на изменени таблицы остатков после вставки проводки(для постоты выкинуты все проверки).
ALTER      trigger [ta_stm] on [dbo].[a_stm] for insert, delete, update
as
BEGIN
-- таблица сгруппированных изменений остатков
  declare @accstm_p table(
    acc  int, 
    datein datetime,
    d dec(19,6), -- изменения по дебету
    c dec(19,6), -- изменения по кредиту
    s dec(19,6), -- изменения остатка 
    ssum dec(19,6), -- изменения остатка с накопление по дате
    d2 datetime null, -- конечная дата интервала при вставке новых
    d2t datetime null, -- конечная дата для обновления остатков
    primary key(acc, datein) 
     )

  insert  @accstm_p
    select acc,datein, sum(d), sum(c), sum(s),0, null, '20651031'
      from (
              select dacc acc,  datein, summa d,   0 c, summa s from inserted
              union all
              select      cacc, datein,       0, summa, -summa  from inserted
              union all
              select dacc, datein, -summa, 0, -summa from deleted
              union all
              select cacc, datein, 0, -summa,  summa from deleted
            ) as c
      group by acc,datein

  update a  --  пересчет интервалов для расчета изменения остатков
    set 
      ssum=(select sum(s) from @accstm_p a1 where a1.acc=a.acc and a1.datein<=a.datein),
      d2t=isnull((select min(datein) from @accstm_p a1 where a1.acc=a.acc and a1.datein>a.datein),'20651031')
    from @accstm_p a
      
  -- запоминаем конечную дату для нового интервала
  -- если datein=a.start_date то мы никакой интервал не найдём, значит надо апдейтить существующий,
  -- а новый вставлять не надо, @accstm_p.d2 тогда будет null
  update t 
    set d2=end_date 
    from @accstm_p t, a_state a 
    where a.acc=t.acc and t.datein>a.start_date and t.datein<a.end_date

  -- уменьшаем старый интервал текущей датой
  update a 
     set end_date=t.datein 
     from @accstm_p t, a_state a 
     where a.acc=t.acc and t.datein>=a.start_date and t.datein<a.end_date and t.d2 is not null
  -- вставляем новый интервал
  insert a_state 
    select t.acc, t.datein, t.d2, 0,0,a.s
    from  @accstm_p t, a_state a 
    where a.acc=t.acc and t.datein>=a.start_date and t.datein=a.end_date and t.d2 is not null
  -- пересчет остатков (за текущую дату и последующие)
  update a  
   set s=a.s+t.ssum 
   from @accstm_p t, a_state a 
   where a.start_date>=t.datein and a.start_date<t.d2t and t.acc=a.acc
  -- пересчет оборотов  (только за текущую дату)
  update a  
   set dt=dt+d, cr=cr+c
   from @accstm_p t, a_state a 
   where a.start_date=t.datein and t.acc=a.acc

END

Т.е. я сначала сгруппированные изменяемые данные(из псевдо-таблиц inserted и deleted) вставляю во временную таблицу(@accstm_p - таблица-переменная, по сути тоже самое). Далее внутри самой таблицы далаем последовательно 2 апдейта. И в конце с помощью ВТ обновляем 4 раза постоянные таблицы. Наверное это можно как-то было сделать и без ВТ(я правда не знаю как) - но это было бы на порядок сложнее и не факт что работало бы быстрее. В данном случае я знаю что вставляемых проводок будет немного (вставляется либо один документ с не более чем десятком проводок, либо удаляется небольшое число документов) и сознательно иду на постоянный скан ВТ.

Ни и основное применение ВТ - конечно в отчетах. Когда надо в одной таблице собрать данные из 18 мест и сделать специфические группировки - я не представляю как это сделать одним запросом, даже если бы были with и connect by

Хотя я не исключаю что несколько испорчен ВТ: на 4-й и 6.5 версиях оптимизатор был очень плохонький и многие запросы работали гораздо быстрее через ВТ, на 2000-м такое встречается гораздо реже(с 7-й версией почти не работал), из нкоторых мест я их даже выкидывал.

Резюме: всякой вещи можно найти достойное применение если применять с умом, а отвергать с ходу не надо.
21 ноя 06, 15:13    [3430233]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
SergSuper
softwarer, Вы несколько категоричны в суждениях (насчет временных таблиц(ВТ))

Может быть, хотя имхо не замечаю. Я просто стремлюсь избежать обсуждения нечетких вопросов, того же вытеснения на диск, и свести к довольно очевидным утверждениям. Скажем, для меня очевидно, что грамотная реализация временной таблицы эффективнее в применении, чем грамотная реализация постоянной, используемой как временной. Почему - потому что у временной не надо заботиться о блокировках, восстановлении после сбоев, а в случае on commit delete rows временной таблицы - еще и об откатах.

SergSuper
Я прекрасно понимаю чего хочет сказать ChA и у меня создаётся такое ощущение что Вы всеми силами пытаетесь объяснить ему что он делает неправильно.

Полным понимаем ChA я похвастаться не могу, что выявилось в этом топике.

Что ChA делает неправильно - если честно, меня как-то не волнует. Мне интересно обсудить некоторые вещи и возможно узнать нечто мне неизвестное - например, если ChA ответит на заданный вопрос то, что я полагаю, я пойму, откуда у трехзвенщиков появился аргумент про желательность быстрой прокачки данных с сервера БД на СП.

SergSuper
если я скажу что надо везде учитывать свою специфику.

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

SergSuper
Ни и основное применение ВТ - конечно в отчетах. Когда надо в одной таблице собрать данные из 18 мест и сделать специфические группировки - я не представляю как это сделать одним запросом, даже если бы были with и connect by

Скажу так, мне хватило опыта работы с Oracle Warehouse Builder, чтобы понять, что практически все на свете можно сделать одним запросом :) Подчеркну - я совершенно нигде не собираюсь настаивать на том, что все и всегда следует делать именно так. Хотя бы с точки зрения сопровождения таких запросов.
21 ноя 06, 15:49    [3430580]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Yo.!!
Guest
о как ловко говорим о временных таблицах, а в коде табличная переменная. надеюсь вы понимаете какой эфект вызвовит использование временной таблицы в вашем коде ? ну и вообще отличие транзакционно-независимой табличной переменной от временной переменной ?
21 ноя 06, 15:54    [3430645]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Yo.!!
о как ловко говорим о временных таблицах, а в коде табличная переменная. надеюсь вы понимаете какой эфект вызвовит использование временной таблицы в вашем коде ? ну и вообще отличие транзакционно-независимой табличной переменной от временной переменной ?

отлично понимаю, разница в данном случае несущественна - не те объёмы, чтоб транзакционно-независимость сказывалась
до 2000-го у меня там была таблица с #, но раз рекомендуют использовать переменные - переделал
да и обман эти табличные переменные - если объявляется табличная переменная, то в tempdb всё равно создаётся временная таблица

суть в общем не в этом
21 ноя 06, 16:18    [3430834]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
softwarer
Скажу так, мне хватило опыта работы с Oracle Warehouse Builder, чтобы понять, что практически все на свете можно сделать одним запросом :) Подчеркну - я совершенно нигде не собираюсь настаивать на том, что все и всегда следует делать именно так. Хотя бы с точки зрения сопровождения таких запросов.

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

кстати а если написать на Оракле такую процедуру:
create proc X as select * from SomeTbl
он выдаст ошибку при компиляции? если нет - то этот select куда-то пойдёт?
21 ноя 06, 16:32    [3430940]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Yo.!!
Guest
SergSuper


суть в общем не в этом

суть именно в этом, ваш код с ВТ работал скорее всего всего лишь из-за низкой загрузки: во первых конструкция insert into #t select блокирует системные таблицы на время всего запроса, т.е. вы просто выставили всех юзеров в очередь, во вторых ВТ вызывает перекомпиляцию сторед процедур, что опять же вызывает ненужный оверхед. именно поэтому МС рекомендует везде где возможно отказатся от ВТ в пользу табличных переменных, которые также вызывают проблемы с перекомпиляцией.

http://support.microsoft.com/default.aspx?scid=kb;en-us;305977
21 ноя 06, 16:33    [3430942]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
SergSuper
Вот конкретный пример, только что делал. Надо сделать отчет о приросте имущества. Но в рублях. Т.е. копейки надо округлить. Некоторые счета должны быть округлены по правилам, некоторые имеют промежуточную сумму и именна она должна быть округлена по правилам(т.к. есть в других отчетах), а по остальным ошибку округления надо равномерно раскидать - делается это итерационным методом. Ну никак тут одним запросом.

Пока что я не увидел ничего, что не делается одним запросом. Хотя согласен с тем, что запрос может оказаться "слишком сложным" итп.

SergSuper
кстати а если написать на Оракле такую процедуру:
create proc X as select * from SomeTbl
он выдаст ошибку при компиляции? если нет - то этот select куда-то пойдёт?

Ээ.... не понял, куда должен пойти этот селект, но пойдет он в баню :) Если Вы имеете в виду параметризованные view, то их к сожалению пока нет, ждем.
21 ноя 06, 16:37    [3430980]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Yo.!!, я работал с MS SQL еще на 4-й версии - ну не надо мне ссылки на доки кидать

insert into #t select не блокирует системные таблицы, блокировал когда-то select * into #t from (создание таблицы и её заполнение тут же), в 7-м (или 2000-м) это исправили, даже если бы блокировал - не все юзеры бы в очереди стояли, а только те кто захотел бы создать таблицу (временную в т.ч.) или еще какой объект

еще раз повторю - не в этом суть, я имел ввиду то, что касается работы оптимизатора

softwarer
Ээ.... не понял, куда должен пойти этот селект, но пойдет он в баню

ну например для MS SQL оба запроса вернут тоже самое
exec X 

select * from SomeTbl 
21 ноя 06, 17:07    [3431286]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
SergSuper
ну например для MS SQL оба запроса вернут тоже самое

Если я правильно понимаю то, что Вы написали, Вы делаете процедуру из единственной строки-селекта с неявным возвращаемым рекордсетом. Как мы тут выясняем N страниц, в Oracle для этого используется ref cursor, написанное Вами просто не соответствует никакой синтаксической конструкции языка. При попытке компиляции такого, думаю, компилятор скажет, что не согласен воспринять SELECT там, где ожидал бы увидеть BEGIN.
21 ноя 06, 17:20    [3431387]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
softwarer
как именно синхронизируются передача данных клиенту с работой продолжающей гнать данные ХП? Кто и что делает в момент, когда единственный выходной буфер заполнен?

Может Вам просто переслать эту книгу, чем ее цитировать ? Там очень много про внутреннюю жизнь MSSQL.
Оттуда же
SQL Server has two input buffers (read buffers) and one output buffer per client. Double-buffering is needed for the reads because while SQL Server reads a stream of data from the client connection, it must also look for a possible attention. (This allows that "Query That Ate Cleveland" to be canceled directly from the issuer. Although the ability to cancel a request is extremely important, it's relatively unusual among client/server products.) Attentions can be thought of as "out-of-band" data, although they can be sent with network protocols that do not explicitly have an out-of-band channel. The SQL Server development team experimented with double-buffering and asynchronous techniques for the output buffers, but these didn't improve performance substantially. The single network output buffer works nicely. Even though the writes are not posted asynchronously, SQL Server doesn't need to bypass the operating system caching for these as it does for writes to disk.

Because the operating system provides caching of network writes, write operations appear to complete immediately with no significant latency. If, however, several writes are issued to the same client and the client is not currently reading data from the network, the network cache eventually becomes full and the write blocks. This is essentially a throttle. As long as the client application is processing results, SQL Server has a few buffers queued up and ready for the client connection to process. But if the client's queue is already stacked up with results and is not processing them, SQL Server stalls sending them and the network write operation to that connection has to wait. Since the server has only one output buffer per client, data cannot be sent to that client connection until it reads information off the network to free up room for the write to complete. (Writes to other client connections are not held up, however; only those for the laggard client are affected.)

Stalled network writes can also affect locks. For example, if READ COMMITTED isolation is in effect (the default), a share lock can normally be released after SQL Server has completed its scan of that page of data. (Exclusive locks used for changing data must always be held until the end of the transaction to ensure that the changes can be rolled back.) However, if the scan finds more qualifying data and the output buffer is not free, the scan stalls. When the previous network write completes, the output buffer becomes available and the scan resumes. But as I stated earlier, that write won't complete until the client connection "drains" (reads) some data to free up some room in the pipe (the virtual circuit between SQL Server and client connection).

If a client connection delays processing results that are sent to it, concurrency issues can result because locks are held longer than they otherwise would be. A kind of chain reaction occurs: if the client connection has not read several outstanding network packets, further writing of the output buffer at the SQL Server side must wait because the pipe is full. Since the output buffer is not available, the scan for data might also be suspended because no space is available to add qualifying rows. Since the scan is held up, any lock on the data cannot be released. In short, if a client application does not process results in a timely manner, database concurrency can suffer.

The size of the network output buffer can also affect the speed at which the client receives the first result set. As mentioned earlier, the output buffer is sent when the batch, not simply the command, is done, even if the buffer is not full. If two queries exist in the same batch and the first query has only a small amount of data, its results are not sent back to the client until the second query is done or has supplied enough data to fill the output buffer. If both queries are fast, waiting for both queries to finish is not a problem. But suppose the first query is fast and the second is slow. And suppose the first query returns 1000 bytes of data. If the network packet size is 4096 bytes, the first result set must wait in the output buffer for the second query to fill it. The obvious solution here is to either make the first command its own batch or make the network packet size smaller. The first solution is probably best in this case, since it is typically difficult to fine-tune your application to determine the best buffer size for each command. But this doesn't mean that each command should be its own batch. Quite the contrary. In fact, under normal circumstances, grouping multiple commands into a single batch is most efficient and is recommended because it reduces the amount of handshaking that must occur between client and server.


softwarer
Этот фрагмент беседы пошел с фразы о том, что если процедура возвращает ref cursor, этот рекордсет может быть использован как клиентом, так и другой серверной ХП, в то время как в MSSQL придется выбирать - то ли "неявный рекордсет", который может быть принят клиентом, то ли курсор, который можно передать в другую ХП. Вы предложили возвращать временную таблицу, которая доступна и так, и эдак. Я постулировал то, что обсуждаем выше - дополнительные накладные расходы.
Если Вы про это
ChA
процедура для возврата данных в вызывающую процедуру или клиенту может быть одна и та же, просто в вызывающей процедуре придется делать возврат рекордсета во временную таблицу или через OPENQUERY, хотя в случае множественных результатов могут быть проблемы.
То здесь говорится совсем не то. Речь только о том, что процедура одна, например
CREATE PROC p
@Id int
AS
SELECT *
FROM Table
WHERE ID = @Id
. В случае возврата клиенту она просто вызывается как
EXEC p 1
, в этом случае все накладные расходы не больше, чем вызвать с клиента
SELECT *
FROM Table
WHERE ID = 1
Но если же надо "задержать" результат на сервере, то ему приходится эмулировать поведение клиента. Так как в MSSQL нет массивов, то проще всего сделать это через временную таблицу
INSERT INTO #t
EXEC P 1
. При этом излишних расходов немногим больше, чем в предыдущем случае. Ровно настолько, что сервер является собственным клиентом и создает для хранения промежуточных результатов временную таблицу. Вы же почему-то упорно считаете, что это "существенные накладные расходы". И все мои попытки донести, что расходы если и есть, то они не настолько уж значительные, чтобы этим заморачиваться всерьез. Типа, суслик есть, но я его не вижу :)
В конце концов, в некоторых ситуациях, когда вы в процедуре только читаете данные, по примеру выше, то можно использовать табличные функции, которые возвращают рекордсет.
CREATE FUNCTION f (
	@id int
)
RETURNS TABLE
AS
RETURN (SELECT name FROM sysobjects WHERE id = @id)
GO
SELECT * FROM dbo.f(1)
GO
DROP function f
Фактически, это view c параметром, и при включении его в другой запрос, он раскрывается для оптимизатора

softwarer
я абсолютно уверен, что в ходе эксплуатации ИС оптимальный план одного и того же запроса меняется, и "я лучше знаю" становится тормозом.
Говоря Вашими же словами - "может стать", но не обязательно становится. Дальнейшее обсуждение этого нюанса, IMHO, бесперспективно. Давайте закончим его обсуждение на том, что зафиксируем разность наших позиций.

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

softwarer
Но программисты, считающие себя умнее оптимизатора, принимают такие решения гораздо чаще. Поэтому я однозначно за "мягкие" решения.
По этому вопросу полностью "за", была бы возможность, я строжайше запрещал бы пользоваться хинтами, пока опыт разработчик БД на конкретной платформе меньше года, как минимум.

softwarer
Не готов оценить "удобство реализации на клиенте". Мне кажется, в этом случае:

1. Необходима механика уборки мусора
2. Необходимо всюду пихать "and session_id = :my_session_id"
3. Накладные расходы на отношение к временной по сути таблице как к постоянной

Здесь я предполагаю, что механизм длинной транзакции с итоговым rollback-ом неприменим - поправьте, если я ошибаюсь.
В случае "псевдовременной":
1. Да, хотя не особо актуально, если добавить идентификатор фильтра.
2. Если доступ через view, то нет, пользователь работает в своей "песочнице".
3. Да, нет, собственно. Вы похоже опять почему-то считаете, что это большие расходы.
4. Длинные транзакции вполне допустимы, с учетом подхода в пункте 2, хотя смысл в длинных транзакциях просто отсутствует.

Yo.!!
http://support.microsoft.com/default.aspx?scid=kb;en-us;305977

Блин, он опять вытащил этот старый жупел :( Это уже просто патология какая-то...
21 ноя 06, 18:22    [3431864]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
Председатель Мао
С точки зрения стоимости владения MS дешевле будет (лицензия дешевле+ специалист в принципе дешевле
Исходя из опыта, специалист определенной квалификации на MSSQL, занимающийся какой-то задачей - стоит столько же сколько и его коллега на Оракл с аналогичной квалификацией занимающийся подобной задачей.
22 ноя 06, 00:20    [3432660]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
Yo.!!
2Председатель Мао

попробуйте осознать одну вещь - pl/sql это язык вырсший из ады (кажется), T-SQL из mssql2k это просто процедурное расширение языка SQL, нет наймспеса (schema/package), нет эксепшенов, там масивов и прочих элементарных атрибутов языка ... но для студента - согласен, проще выучить пару конструкций и в перед.

MS SQL2k5, с эксепшенами, с встроенный обходом деревьев и т.п. - вышел год назад.
22 ноя 06, 00:23    [3432663]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
andsm
Yo.!!
2Председатель Мао

попробуйте осознать одну вещь - pl/sql это язык вырсший из ады (кажется), T-SQL из mssql2k это просто процедурное расширение языка SQL, нет наймспеса (schema/package), нет эксепшенов, там масивов и прочих элементарных атрибутов языка ... но для студента - согласен, проще выучить пару конструкций и в перед.

MS SQL2k5, с эксепшенами, с встроенный обходом деревьев и т.п. - вышел год назад.


Тока вот жалка пакеты до сих пор в и т.п. не входють :(
22 ноя 06, 08:06    [3432863]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Yo.!!
Guest
SergSuper
Yo.!!, я работал с MS SQL еще на 4-й версии - ну не надо мне ссылки на доки кидать

insert into #t select не блокирует системные таблицы, блокировал когда-то select * into #t from (создание таблицы и её заполнение тут же), в 7-м (или 2000-м) это исправили, даже если бы блокировал - не все юзеры бы в очереди стояли, а только те кто захотел бы создать таблицу (временную в т.ч.) или еще какой объект

кто сказал исправили ? совсем недавно мы тут с кем-то проверяли на mssql2k5 косяк отлично работает.

2andsm
Мао сравнивал pl/sql 9ки и t-sql sql2k
22 ноя 06, 12:18    [3434320]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
f2f
Guest
С разделение понятия USER и SCHEMA это, на мой взгляд, уже не так страшно.
Можно просто использовать схемы для группировки объектов.
22 ноя 06, 12:27    [3434435]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
если это про пакеты - то они НЕ ТОЛЬКО группировка объектов
22 ноя 06, 12:38    [3434526]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
ChA
Может Вам просто переслать эту книгу, чем ее цитировать ? Там очень много про внутреннюю жизнь MSSQL.

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

Оттуда же
If a client connection delays processing results that are sent to it, concurrency issues can result because locks are held longer than they otherwise would be. A kind of chain reaction occurs: if the client connection has not read several outstanding network packets, further writing of the output buffer at the SQL Server side must wait because the pipe is full. Since the output buffer is not available, the scan for data might also be suspended because no space is available to add qualifying rows. Since the scan is held up, any lock on the data cannot be released. In short, if a client application does not process results in a timely manner, database concurrency can suffer.

Ага. Вот этого я ожидал после предыдущего письма. Виноват, гипотеза насчет накопления данных на сервере была вызвана предположением, что уж вышеописанным-то образом делать не станут.

Что ж, так действительно становятся понятнее некоторые странные ранее аргументы трехзвенщиков. Прошу прощения за неверное предположение, не ожидал, что архитекторы MSSQL допустят такую зависимость.

ChA
Фактически, это view c параметром, и при включении его в другой запрос, он раскрывается для оптимизатора

Да, это очень приятная фича. Единственно я не понимаю, почему оно называется "функцией" :)

ChA
Говоря Вашими же словами - "может стать", но не обязательно становится.

Безусловно, для каждого отдельного запроса - "может стать". Мне следовало выразиться четче, примерно так: из многих "может стать" некоторые наверняка станут.

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

Зависит от. Прежде всего, в Oracle хватает хинтов со смыслом "вот здесь вот этого не делать". Есть и другие моменты - например, оптимизатор может принимать неверное решение из-за отсутствия информации о количестве строк во временной таблице или в результате табличной функции, и здесь хинт cardinality, не запрещая оптимизатору выбирать оптимальный путь, исправит ситуацию.

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

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

ChA
1. Да, хотя не особо актуально, если добавить идентификатор фильтра.

Ээ.. не понял. Либо мы убираем мусор, либо он потихоньку забивает таблицу. Третьего варианта я не вижу.

ChA
2. Если доступ через view, то нет, пользователь работает в своей "песочнице".

Признаться, не доводилось слышать, чтобы где-нибудь был реализован параметризованный updateable view.

ChA
3. Да, нет, собственно. Вы похоже опять почему-то считаете, что это большие расходы.

Да, я полагаю накладные расходы на работу с временными таблицами меньшими, нежели с постоянными. Данные во временных таблицах не обязаны пережить падение сервера, а следовательно нет потребности постоянно дергать диск. Данные разных сессий не путаются между блоками/страницами, нет необходимости выставлять-поддерживать-проверять блокировки.
22 ноя 06, 13:04    [3434776]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Yo.!!
кто сказал исправили ? совсем недавно мы тут с кем-то проверяли на mssql2k5 косяк отлично работает.

Yo.!!, блин, ну надо же так разочаровать, а вот я до этого серьёзно относился к Вашим словам. Теперь не буду.

Зачем писать о том, в чем Вы не разбираетесь и слышали краем уха? Ну это еще ладно, но врать то зачем?
Интересно, косяк Вы(а точнее кто-то с кем Вы якобы проверяли) умудрились найти на какой конструкции: на insert into #t select(как считали недавно) или select * into #t? Вы хоть представляете причины такой блокировки?

При создании любой таблицы происходит вставка записи о ней в системную таблицу sysobjects. В версиях 6.5 и раньше вставка в таблицу блокировала последующие вставки в неё. Поскольку отдельный оператор - это отдельная транзакция, а select * into #t создаёт таблицу, то на время этой транзакции sysobjects была заблокирована, а транзакция длилась пока этот select шел. В 7-й версии уже появилась неблокирующая вставка в таблицу и таких косяков не было.

Специально сейчас проверил на 2000-м - не блокирует. 2005-го у меня нет, но уверен что и там не будет.

softwarer
ChA
Фактически, это view c параметром, и при включении его в другой запрос, он раскрывается для оптимизатора


Да, это очень приятная фича. Единственно я не понимаю, почему оно называется "функцией" :)

Есть еще т.н. табличная функция - типа процедуры, но модифицировать она может внутри себя только таблицы-переменные (т.е. можно делать внутренние промежуточные вычисления) и можно делать select из этой функции. Поскольку по синтаксису они довольно похожи - то и назвали функцией.
22 ноя 06, 14:31    [3435545]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Yo.!!
Guest
SergSuper

Yo.!!, блин, ну надо же так разочаровать, а вот я до этого серьёзно относился к Вашим словам. Теперь не буду.

Зачем писать о том, в чем Вы не разбираетесь и слышали краем уха? Ну это еще ладно, но врать то зачем?

пока еще Yo! на откровенной лаже никто не ловил ;)

SergSuper

При создании любой таблицы происходит вставка записи о ней в системную таблицу sysobjects. В версиях 6.5 и раньше вставка в таблицу блокировала последующие вставки в неё. Поскольку отдельный оператор - это отдельная транзакция, а select * into #t создаёт таблицу, то на время этой транзакции sysobjects была заблокирована, а транзакция длилась пока этот select шел. В 7-й версии уже появилась неблокирующая вставка в таблицу и таких косяков не было.

Специально сейчас проверил на 2000-м - не блокирует. 2005-го у меня нет, но уверен что и там не будет.

ну давайте вместе читать о чем я вам толкую "конструкция insert into #t select блокирует системные таблицы на время всего запроса", разницу между запросом и транзакцией надеюсь чуете ? а что вы там тестировали ? я не утверждал, что лок поставится на всю транзакцию, я говорил о запросе т.е. на время "insert into #t select"

уверен что на "select * into #t" вылезет тот же косяк, т.к. проблема в том, что локи выставляются на время создания таблицы.

ЗЫ. интересно, что майкрософт до сих пор утверждает, что лок в sql2k ставится на всю транзакцию :)
22 ноя 06, 19:47    [3438051]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32898

Привет, Yo.!!!
Ты пишешь:

Yo.!!
Y> пока еще Yo! на откровенной лаже никто не ловил ;)
ну, если Yo!, Yo!! и Yo.!! - разные люди, то тогда конечно...

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

22 ноя 06, 19:51    [3438055]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Ж:-)
Guest
Yo.!!
пока еще Yo! на откровенной лаже никто не ловил ;)


Вспомнился анекдот про вратаря-армянина

Один тренер создал футбольную команду которая всех обыгрывала, и бразильцев, и немцев...
Его спрашивают как он это сделал?
Тренер отвечает:
-В нападение поставил чеченцев -
от них трудно отбиться, в полузащиту
грузин - с ними трудно договориться,
в защиту азербайджанцев - пока не
заплатишь не пройдешь, а в ворота
армянина - даже если забьешь гол, не докажешь
22 ноя 06, 22:29    [3438378]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Председатель Мао
Member

Откуда:
Сообщений: 79
Мимопроходящий

Привет, Yo.!!!
Ты пишешь:

Yo.!!
Y> пока еще Yo! на откровенной лаже никто не ловил ;)
ну, если Yo!, Yo!! и Yo.!! - разные люди, то тогда конечно...

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3


Мне кажется это один человек, причем откуда-то из Украины ключевое слово "чуете" неоднакратно упоминается в его различных постах.
22 ноя 06, 22:39    [3438401]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
Yo.!!
Guest
2Мимопроходящий

url с отковенной лаже в студию :) тока чур в отдельной ветке.

2Председатель Мао

естественно один человек, но не с украины.

к стате ходящий нельзя бы поудалять придурков зарегистрированых с моим именем Yo! и Yo!! и возвернуть мне доброе имя :) ?
22 ноя 06, 23:03    [3438437]     Ответить | Цитировать Сообщить модератору
 Re: СУБД для учета финансовых потоков?  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
softwarer
Оттуда же
If a client connection delays processing results that are sent to it, concurrency issues can result because locks are held longer than they otherwise would be. A kind of chain reaction occurs: if the client connection has not read several outstanding network packets, further writing of the output buffer at the SQL Server side must wait because the pipe is full. Since the output buffer is not available, the scan for data might also be suspended because no space is available to add qualifying rows. Since the scan is held up, any lock on the data cannot be released. In short, if a client application does not process results in a timely manner, database concurrency can suffer.

Ага. Вот этого я ожидал после предыдущего письма. Виноват, гипотеза насчет накопления данных на сервере была вызвана предположением, что уж вышеописанным-то образом делать не станут.

Что ж, так действительно становятся понятнее некоторые странные ранее аргументы трехзвенщиков. Прошу прощения за неверное предположение, не ожидал, что архитекторы MSSQL допустят такую зависимость.
Я делаю правильный вывод из Вашей фразы, что накапливают - плохо и не накапливают - тоже плохо ? Что есть тогда хорошо ? Или, лучше, как поступает Oracle ? Можно цитату на аналогичную тему из документации ?

И, кстати, давайте не будем трогать трехзвенщиков в контексте нашего обсуждения ? Это совершенно отдельная и большая тема. И не думаю, что они работают только на платформе MSSQL и только поэтому используют то, что Вы называете "странными аргументами". Так что предлагаю закрыть пока эту нить.

softwarer
ChA
Говоря Вашими же словами - "может стать", но не обязательно становится.
Безусловно, для каждого отдельного запроса - "может стать". Мне следовало выразиться четче, примерно так: из многих "может стать" некоторые наверняка станут.
Предлагаю эту нить обсуждения также завершить. Ничего нового для себя мы из нее не выясним.

softwarer
ChA
Мне хотелось бы понять, как можно "отвадить оптимизатор от явно неверных решений". Как пнуть его в нужную сторону, я понимаю, а вот как отвадить - нет, или не понимаю, что именно Вы имеете в виду под "отвадить".
в Oracle хватает хинтов со смыслом "вот здесь вот этого не делать".
Хотя бы парочку примеров таких запретительных хинтов с кратким пояснением можете привести ? В MSSQL(2000) ничего похожего нет, либо я не в курсе.
softwarer
например, оптимизатор может принимать неверное решение из-за отсутствия информации о количестве строк во временной таблице или в результате табличной функции, и здесь хинт cardinality, не запрещая оптимизатору выбирать оптимальный путь, исправит ситуацию.
В Oracle есть временные таблицы и табличные функции ? Или подразумевается MSSQL ? Если второе, то статистика как по временной таблице так и по табличной функции, в общем случае, существует, во втором случае - косвенно, через раскрытие функции оптимизатором до базовых таблиц. Хинт cardinality отсутствует, и не то, чтобы было сильно жаль, но его наличие могло бы быть полезным в определенных случаях.
Таких хинтов, насколько понимаю, в Oracle на порядок больше, чем у MSSQL, что в значительной степени сложилось, как предполагаю, исторически. Когда оптимизатор был еще не очень качественным и требовалось много подсказок, чтобы он либо шел, либо не шел в заданном направлении. Большинство из них наверняка сейчас выглядят анахронизмом, так как оптимизатор и так вполне справляется в большинстве случаев.

softwarer
ChA
И если я не найду других способов вернуть его поведение к более адекватному, то я воспользуюсь хинтами.

Напомню, я в данном случае не возражаю против хинтов (хотя конечно по-разному отношусь к разным хинтам и их уместности). Мы вроде бы говорили о жестком разбиении запроса на подзапросы.
В некотором смысле это тоже хинт. Более того, я знаю, как в некоторых ситуациях хинтами добиваться использования оптимизатором внутренних временных таблиц. Можно также считать, что это своеобразный хинт "наоборот" о котором Вы поминали в Oracle, я явно говорю оптимизатору, что туда ходить не надо, пусть и таким своеобразным способом. На всякий, еще раз процитирую
ChA
который вполне может сам использовать внутренние временные таблицы, если найдет это полезным. А если я создаю эти таблицы явно и буду их использовать, то это, в принципе, ничем не отличается от того, что делает сервер.
Как следствие, сервер будет терять гораздо меньше времени на построение или перестройку плана в следующий раз. И вызвано это следующим
ChA
встречался с запросами, компиляция которых настолько превышает время выполнения, что приходится делать телодвижения, дабы избегать таких несуразностей. В том числе, переписывая запрос, вплоть до разбиения его на последовательность более простых. Разумеется, это не частое явление, но изредка бывает. А если учесть, что запросы все равно время от времени перекомпилируются, например, при изменении табличных статистик, то можно заранее подстраховаться и сделать поведение более предсказуемым.
Прошу обратить внимание на подчеркнутую фразу и не считать это постоянной практикой, так же как наличие хинтов не подразумевает их обязательного использования. Но если мы идем определенным путем, то он выбран в здравом уме и твердой памяти, с четким осознанием последствий, о чем упоминается уже не в первый раз. Патологические случаи предлагаю не рассматривать.
Возможно, в Oracle все гораздо лучше и при любых условиях хинты не используются, либо - невероятно редко, а запросы никогда не упрощаются разбиением на подвыборки, какими бы сложными они не были. Ну, тогда остальным придется только завидовать.

softwarer
ChA
1. Да, хотя не особо актуально, если добавить идентификатор фильтра.

Ээ.. не понял. Либо мы убираем мусор, либо он потихоньку забивает таблицу. Третьего варианта я не вижу.
Я, по моему, согласился, что он необходим, разве нет ? Просто отсутствует необходимость сразу же все удалять, а можно отложить этот процесс на окончание текущей или начало следующей сессии, либо время от времени устраивать чистку от "мусора" хоть на основе расписаний, хоть степени активности. В принципе, я лично, за использование временных таблиц в подобной ситуации, но такой подход сложился отчасти по историческим причинам и в принятии решения по этому поводу я, к сожалению, участия не принимал.
Кстати, временные таблицы тоже придется чистить. Либо пересоздавать, причем на самом верхнем уровне, если хотим, чтобы к ним можно было обращаться не из взаимосвязанных по коду процедур. Увы, но временная таблица, созданная в процедуре, "умирает" по окончанию выполнения этой процедуры.

softwarer
ChA
2. Если доступ через view, то нет, пользователь работает в своей "песочнице".

Признаться, не доводилось слышать, чтобы где-нибудь был реализован параметризованный updateable view.
Зачем параметризованные-то ?
CREATE TABLE t (spid smallint DEFAULT @@SPID, id int, PRIMARY KEY(spid, id) )
GO
CREATE VIEW v 
AS SELECT id FROM t WHERE spid = @@SPID
GO
INSERT INTO v SELECT TOP 3 id FROM sysobjects ORDER BY id
SELECT * FROM t
DELETE v WHERE id = 1
SELECT * FROM t
GO
DROP VIEW v
DROP TABLE t
spid   id          
------ -----------
51 1
51 2
51 3

spid id
------ -----------
51 2
51 3
Естественно, пользователю даны права только на использования VIEW v.

softwarer
ChA
3. Да, нет, собственно. Вы похоже опять почему-то считаете, что это большие расходы.

Да, я полагаю накладные расходы на работу с временными таблицами меньшими, нежели с постоянными. Данные во временных таблицах не обязаны пережить падение сервера, а следовательно нет потребности постоянно дергать диск. Данные разных сессий не путаются между блоками/страницами, нет необходимости выставлять-поддерживать-проверять блокировки.
Вообще говоря, опять же ненамного. Нет необходимости дергать диск, зато активно пользуем ОЗУ, хотя это, в принципе, и не факт, так как в случае большой временной таблицы, чего желательно избегать, при недостатке ОЗУ может быть тот же самый псевдосвоппинг. Если множество изменений делать в единой транзакции, то диск точно так же не будет дергаться, пока мы не озаботимся ее фиксацией.

Если в физическом смысле, то данные разных сессий и так не будут путаться между, если сделать правильный кластерный индекс. На логическом уровне клиенту все равно, он видит и работает только со своими данными.

Блокировки, к сожалению, даже в этом случае используются, хотя и менее активно. Некоторые ставятся практически всегда, типа Schema-stability, другие в определенных случаях, например, потенциальной параллелизации запросов с использованием временных таблицы. Тут ничего более внятного сказать на данный момент не могу, так как этот вопрос меня не особо интересовал. По принципу, если их ставят, значит так нужно и есть разумное объяснение этому поведению. Я не претендую на то, что лучше разработчиков MSSQL знаю, когда их надо применять, а когда нет. Мне пока достаточно понимать, как и зачем я использую свои собственные блокировки.
23 ноя 06, 00:10    [3438521]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить