Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 14 15 16 17 18 [19] 20 21 22 23 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Чернышев Андрей Леонидович
Как всегда трусость и жалость к себе недоучек "реляционщиков" берет верх в их собственном сознании над простым человеческим желанием чему-то научиться. Я этих "оппонентов" уже хорошо изучил.


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

Заблуждаться - не позор. А взрослому мужику вести себя подобно тинэйджеру - стыдно.
5 ноя 06, 04:32    [3357695]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
kvasov
c127
Там кроме прочего было сказано примерно, что фраза
kvasov> но это фантазии, а критерий конкурентоспособности реален и прост как тапок - доходы должны превышать расходы

лишена смысла и говорит о том, что ее автор не понимает о чем говорит. Польностью согласен.


ну не знаю, мне этот момент понравился вот в этой книжке
http://www.duel.ru/publish/parshev/why2.htm

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

Не знаю, что такое конкурентноспособность, но абслютно точно не то, что Вы написали. В критерии конкурентноспособности должны упоминаться как минимум конкуренты.

Sergei Obrastsov
c127
Я думал это очевидно, видно у М-фанатов совсем с образованием туго.
Пример. Пусть q1,q2 это преподаватели, s1,s2 это студенты. Ребро (d,f) значит что люди d,f связаны отношением учит-учится.
Граф: множество вершин: {q1,q2,s1,s2}
множество ребер: {(q1,s1),(q1,s2),(q2,s1),(q2,s2)}
ВНИМАНИЕ, ЦИКЛ:
q1-s1-q2-s2-q1

 q1 $---------$ q2
    |\        |\
    | \       | \
    $  $      $  $
    s1 s2     s1 s2 

Повторите, пожалуйста, еще раз Вашу методику обхода.

Почитайте, пожалуйста, что я говорил неделю назад:
"Например можно создать другое дерево, где это ребро есть, но прийдется поддерживать целостность между двумя деревьями"
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=9#3317847

Это именно то, что Вы предлагаете, Вы создали копии s1,s2, в результате цикл исчез, но появилось второе дерево. Это не тот же граф, который в моем примере, но это не важно.

Теперь в Вашей схеме левое и правое поддеревья никак не связаны, система не знает что s_i слева эквивалентны соответствующим s_i справа. Если s1,s2 имеют аттрибуты, которые можно редактировать, например домашний адрес студентов s1 и s2, то изменив адрес у левого нужно не забыть изменить его в правом. Как ни крути, а проблема остается, либо у граф не дерево и с ним в иерархических М системах работать неудобно, либо поддерживаем целостность руками.

Sergei Obrastsov
Итого, у нас 2 массива. Это два дерева, а не одно.


Вот то-то и оно.
5 ноя 06, 06:04    [3357706]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Это называется "правда глаза колет", аббревиатуры vadiminfo и ЗлОй. И с прямоугольничком опять словчили, ЗлОй, так, как никакому тинейджеру не удастся. И профессионалом себя не поленились назвать. Настоящий мужик !
Вы меня просто вынуждаете начинать с констатации фактов Вашего не профессионального поведения. И я всегда буду отвечать на многочисленные оскорбления адекватно.
Теперь по существу.
Какое неудобное для меня предложение(я) (ведь мне тоже можно предъявить такую претензию) Вы видите в сообщении, из которого я взял предложение о количестве запросов в проектах ?
Может быть я что-то переврал в рассуждении о количестве запросов в приложениях ?

Что Вы не поняли в рассмотренном здесь конкретном примере с преподавателями и студентами, наглядно показавшем слабости "Р"СУБД ?
В ОСУБД на MUMPS: объявили схему БД
Преподаватель<--Учит/Учится у-->Студент
и соответсвующие характеристики объектов Преподаватель и Студент.

Все. Дальше работают пользователи "нашего" приложения. Выбрали преподавателя - видят студентов, которые у него учатся. Выбрали одного из этих студентов и посмотрели у каких он учится преподавателей. Задали условие на связи Студент<--Учится у-->Преподаватель "Число привязанных>2" (пример SergSuper) и в той же схеме видят результат (ведь результатом "запроса" является подсхема схемы БД с присущей БД семантикой, о чем уже подзабыли за увлечением "алгеброй"). И т.д., и т.п. Без всякого участия "разработчиков". Благодаря естественным для БД идентификации, навигации и семантике.

Это дореляционная технология ? Безусловно. Что же мне врать, что она "постреляционная"?

Но нашим "аббревиатурам" невыгодно обращать на это какое-то внимание. Это вредит их карьере, и обесценивает их знания. Спокойнее смеятся над "нафигаторами" и давать ЧАЛу разные определения.
А я использую одно - банальные недоучки. И всегда это доказываю. И не считаю, что на это стоит обижаться. Я не обижаюсь, когда меня называют недоучкой, и объясняют чему именно я не доучился. Вот стали мне говорить, что я не доучился РМД, но выяснилось, что наоборот - я ее слишком глубоко изучил. Можно было поверхностно изучить и стать "нормальным человеком", и программировать на SQL.
5 ноя 06, 10:31    [3357765]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Очередной шедевр "реляционного профессионала":

"Теперь в Вашей схеме левое и правое поддеревья никак не связаны, система не знает что s_i слева эквивалентны соответствующим s_i справа. Если s1,s2 имеют аттрибуты, которые можно редактировать, например домашний адрес студентов s1 и s2, то изменив адрес у левого нужно не забыть изменить его в правом. Как ни крути, а проблема остается, либо у граф не дерево и с ним в иерархических М системах работать неудобно, либо поддерживаем целостность руками."

Можно сколько угодно повторять как именно профессионалы используют MUMPS, что в MUMPS не иерархическая модель данных, что связи в естественной для MUMPS ОБД поддерживаются между идентификаторами и симметричнно, что целостность поддерживается автоматически. А "реляционные профессионалы" о чем-то о своем, о наболевшем...
5 ноя 06, 10:47    [3357773]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Зл0й

В общих чертах почитайте здесь:

http://www.dia.uniroma3.it/~vldbproc/006_019.pdf


Это интересно. Буду читать. Спасибо.

Зл0й

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

Да не обязательно, что всегда нельзя выбрать лучший план запроса, чем это сделал оптимизатор. Тем более я приводил тоже случай когда оптимизатор этого не может и при собранной статистике. Но в утверждении был квантор всеобщности
AndreiNz

в Оракле надо в каждом запросе указывать, какой индекс использовать.

Т.е. обязательно хинт указывать в каждом запросе. Т.е. в утвержденни – обязательно можно в каждом запросе превзойти оптимизатор, у которого есть вся инфа. Все еще думаю, что это не так. Особенно, стмневаюсь что конкретно мне и AndreiNz это удастся сделать в каждом запросе. А значит и многим другим, хотя и создавшим успешные системы на Оракле.

Зл0й

У вас задачки невеликие (без обид). У меня на работе хранилище данных на 40 терабайт, заливаем 200 гиг каждый час. Соответственно весь ораклячий ETL собран на хинтах, чтобы гарантировано работало. Иначе если начнет тормозить - не расхлебаем. Просто не успеем - каждые 5 часов простоя это примерно терабайт накопившийся для обработки.

Да невеликие. Но с другой стороны, я говорил про OLTP системы. А Вы говорите про хранилище данных? Конкретно про заливку в него данных (в целом это физическое больше)? Думаю, что тут уже не до теорий. Хорошо, конечно и там логическое от влияние физического избавить. Но там строго, говоря уже не РМД в чистом виде рулит (сам Кодд, по моему, говорил, что РМД никогда для этого не предназначалась), хотя и могут использоваться и используются так или иначе реляционные структуры и манипулирование данными. В общем случае, там данные и от других (не реляционных) систем могут быть. По моему, там на сегодняшний день все средства хороши. И если сравнивать решения производителей Скулевых СУБД с Кашей, а тем более МУМПСом, то там, скорее всего, не до хинтов будет. Впрочем, это пока только предположение.
5 ноя 06, 12:54    [3357841]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
c127

Это именно то, что Вы предлагаете, Вы создали копии s1,s2, в результате цикл исчез, но появилось второе дерево. Это не тот же граф, который в моем примере, но это не важно.

Ну а теперь вернемся к РМД. Деревьев у Вас нет, а связи поддерживаются, следовательно есть циклы? Что ж Вы так презрительно тычете в нашу сторону?
Или опять последует глубокомысленное "а я не думаю об этом, пусть СУБД думает"?

c127

Теперь в Вашей схеме левое и правое поддеревья никак не связаны, система не знает что s_i слева эквивалентны соответствующим s_i справа.

Это уже мои проблемы как программиста. Но на уровне объектов и встроенного
SQL такая целостность поддерживается автоматически.

c127

Если s1,s2 имеют аттрибуты, которые можно редактировать, например домашний адрес студентов s1 и s2, то изменив адрес у левого нужно не забыть изменить его в правом. Как ни крути, а проблема остается, либо у граф не дерево и с ним в иерархических М системах работать неудобно, либо поддерживаем целостность руками.

Не стоит считать других глупее себя. Я, например, не догадался, что адрес можно привесить к каждому появлению "студента" в БД.
5 ноя 06, 16:02    [3357992]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
vadiminfo
И если сравнивать решения производителей Скулевых СУБД с Кашей, а тем более МУМПСом, то там, скорее всего, не до хинтов будет. Впрочем, это пока только предположение.

Можно пояснить эту фразу? А то она трактуется в обе стороны.
5 ноя 06, 16:07    [3357997]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Мне кажется, "придираться" к аббревиатуре с127 с "циклами" - это уж чересчур завышенные требования. Даже Дейт не обратил внимания на "циклы", когда написал (по понятным причинам), что разумно было бы и связи "многие к одному" представлять отдельными отношениями (что, конечно же, приводит к бесконечному "циклу").
5 ноя 06, 18:28    [3358110]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kvasov
Member [заблокирован]

Откуда:
Сообщений: 853
Зл0й
У меня на работе хранилище данных на 40 терабайт


это что - 160 дисков по 500 гигабайт? %-)
и сколько же ОЗУ тогда ?
как узнаете, что какой-то диск сломался?
и какие диски оказались самыми ненадежными?
Вы в наушниках обслуживаете такую аппаратуру - это ж какой звон там?
какой аппарат такой юзаете?
дожидаетесь пока диск какой сломается, или по ресурсу меняете на новые?
5 ноя 06, 22:55    [3358376]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
OS/360
Guest
2 kvasov : компьютеры бывают не только настольными и персональными
http://www-03.ibm.com/servers/storage/disk/
6 ноя 06, 00:41    [3358506]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
Sergei Obrastsov
c127

Это именно то, что Вы предлагаете, Вы создали копии s1,s2, в результате цикл исчез, но появилось второе дерево. Это не тот же граф, который в моем примере, но это не важно.

Ну а теперь вернемся к РМД. Деревьев у Вас нет, а связи поддерживаются, следовательно есть циклы?

Посылка неверна, в РСУБД могут быть деревья, может не быть, зависит от интерпретации. В РСУБД есть множества и кортежи, которые тоже множества. Это иерархические СУБД основаны непосредственно на деревьях, РСУБД основаны непосредственно на множествах.

Sergei Obrastsov
Что ж Вы так презрительно тычете в нашу сторону?
Или опять последует глубокомысленное "а я не думаю об этом, пусть СУБД думает"?

Не последует, посылка неверна. В очередной раз советую почитать хоть что-нибудь по теории баз данных, чтоб не постить глупости.

Sergei Obrastsov
c127

Теперь в Вашей схеме левое и правое поддеревья никак не связаны, система не знает что s_i слева эквивалентны соответствующим s_i справа.

Это уже мои проблемы как программиста. Но на уровне объектов и встроенного
SQL такая целостность поддерживается автоматически.

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

Что же касается постоянного кивания на Ваши проблемы как программиста, то это и есть ассемблеровский подход, решить можно все, но все проблемы на прграммисте.

Sergei Obrastsov
c127

Если s1,s2 имеют аттрибуты, которые можно редактировать, например домашний адрес студентов s1 и s2, то изменив адрес у левого нужно не забыть изменить его в правом. Как ни крути, а проблема остается, либо у граф не дерево и с ним в иерархических М системах работать неудобно, либо поддерживаем целостность руками.

Не стоит считать других глупее себя. Я, например, не догадался, что адрес можно привесить к каждому появлению "студента" в БД.

А где же хранится домашний адрес? Нарисуйте на Вашей схемке, сразу многое прояснится и возможно мы в очередной раз увидим как дерево превращается в граф с циклом.

Как я понимаю, с циклами мы разобрались и больше вопросов нет. Только не ходите по кругу.
6 ноя 06, 01:40    [3358572]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
mumps-ист
Guest
Чернышев Андрей Леонидович
Я не коммерсант, и не маркетолог, уважаемый (опять) неизвестно кто.


ЧАЛ, вы сначала говорите "Собственно, никому так и не удолось привести хотя бы один пример типового приложения, для которого "Р"СУБД были бы эффективнее, чем ОСУБД на MUMPS".

Когда Вас спрашивают, как можно посмотреть на "ОСУБД на MUMPS", вы отвечаете: "Я не коммерсант, и не маркетолог" и "прекратите лгать, vadiminfo. Никогда не существовало, и не существует никакой "моей ОМД".".

Потом вы всем рассказываете, что есть чудо-система (если не ошибаюсь "ОСУБД на MUMPS"), где вы каким-то образом задаете, что есть студенты и ученики и связь между ними и все остальное как-то само-собой получается, включая запросы, проддержку целостности данных ит.п.

Вам не кажется, что в ситуации, когда Вы не можете никому продемонстировать не то что конечное решение на "ОСУБД на MUMPS", но даже и саму "ОСУБД на MUMPS", то Вам стоит просто помолчать? Вы же ни одного свего слова не можете подкрепить примером. Я с таким же успехом могу заявить, что есть РСУБД, в которой не потеряна "идентификации, навигации и семантики данных" и что я ей наговариваю в микрофон про струткуру данных, а дальше она делает все сама и в 100 раз быстрее, чем "ОСУБД на MUMPS".
Когда меня спросят, что за СУБД - я скажу "Я не коммерсант, и не маркетолог". Похоже на десткий сад. Тот факт, что Вы не можете предоставить ссылку на "ОСУБД на MUMPS" говорит о том, что Вам в этом топике говорить не о чем - откройте тему в "Просто треп" - там механизмы работы "ОСУБД на MUMPS" более к месту.
6 ноя 06, 03:59    [3358658]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Аббревиатура с127 разобралась с "циклами" ? Не может этого быть. Даже Дейт не разобрался.
6 ноя 06, 16:08    [3359776]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Ну не сочиняйте, очередная аббревиатура, пожалуйста. Здесь недоучек и лжецов и без вас хватает.
Конечно, нет никакой "моей ОМД". Реализаций различных МД (в том числе и ОМД) на MUMPS было и есть множество. Лень писать свою - используйте существующие.
Что за "чудо" ? Разве я не банальные и естественные вещи говорю ? Почему же "чудо"? Этому "чуду" десятки лет. Позорно не знать этого, занимаясь базами данных. Так что помолчать нужно вам. Или "наговаривайте в микрофон структуру данных РСУБД", кто вам мешает ?
Я не коммерсант и не маркетолог. Я ничего не рекламирую, а только сообщаю вам подобным то, о чем они просто не знают. И - главное - не хотят знать (классический пример - упорно дурака валяющие аббревиатуры с127, vadiminfo, mumps-ист). Заинтересованные специалисты давно познакомились с тем, что их интересовало.
6 ноя 06, 16:18    [3359801]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Сколько лет вы работаете с MUMPS, mumps-ист ?
И какие сделали приложения (насколько я понял напрямую "на глобалах") ?
6 ноя 06, 16:26    [3359836]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Чернышев Андрей Леонидович
.... обводя в прямоугольнички только "нужные" предложения....
Андрей Леонидович, голубчик, хотите я Вам тайну открою? Чтобы "обвести в прямоугольничек" достаточно нажать ссылку "цитировать" и удалить из текста оппонента то, что в прямоугольничек обводить не нужно. только [quot и [/quot не стирайте
6 ноя 06, 16:36    [3359871]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Спасибо Вам большое, тоже голубчик, Павел!
Давно Вас не слышал. Ну Вы же понимаете что я имею в виду про "бесконтекстный анализ текстов шизофреника ЧАЛа". Мне эта "технология" не нужна. Что касается технического аспекта, то пока у меня не было ситуации, в которой это было бы эффективнее обычного копирования (раз уж даже подстановку идентификатора сообщения до сих пор не реализовали); видимо это когда из многих сообщений нужно цитировать в одно свое. Но, еще раз, большое спасибо.
6 ноя 06, 17:07    [3359988]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Павел Воронцов
Андрей Леонидович, голубчик, хотите я Вам тайну открою?

Для одной цитаты не эффективно.
6 ноя 06, 17:12    [3360005]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
###
Member

Откуда: Курумоч
Сообщений: 658
Чернышев Андрей Леонидович
Павел Воронцов
Андрей Леонидович, голубчик, хотите я Вам тайну открою?

Для одной цитаты не эффективно.
УРАААаааа!!! Он научился!!!
6 ноя 06, 17:22    [3360036]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Кстати, 19-го должен приехать в Новосибирск. Было бы интересно взглянуть на какой-то "центр технологий БД" в другом городе, тем более, таком научном.
6 ноя 06, 17:24    [3360039]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Понимаю, что сидя за решеткой трудно научиться технологям БД. Так что мне УРА! так, видимо, и не доведется прокричать.
6 ноя 06, 17:27    [3360048]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Чернышев Андрей Леонидович
Кстати, 19-го должен приехать в Новосибирск. Было бы интересно взглянуть на какой-то "центр технологий БД" в другом городе, тем более, таком научном.
Wow! Ну приходите, покажу. Только не БД, а финансовых. Так у нас фирма называется - ЦФТ.
6 ноя 06, 18:12    [3360205]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
###
Member

Откуда: Курумоч
Сообщений: 658
Чернышев Андрей Леонидович
Понимаю, что сидя за решеткой трудно научиться технологям БД. Так что мне УРА! так, видимо, и не доведется прокричать.
Соболезную...
Давно сели? А как же Новосибирск? Неужто по этапу?
6 ноя 06, 18:35    [3360279]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Чернышев Андрей Леонидович

Может быть я что-то переврал в рассуждении о количестве запросов в приложениях ?

Неужели Вы Ваши мысли называете рассуждениями? Вы совсем не самокртитчны. А Вам как ни кому другому это было бы полезно.
А про то, что на SQL на местах никто писать запросы не может выдали желаемое за действительное (сказать , что соврали - сделать слишком сильное предположение, что Вы что-то знаете про РМД). И уж тем более писать запросы по просьбе каждого из пользователя - это что-то из жизни систем у которых 1-3 пользователя. Скорее всего это Ваш опыт на Балабановской спичечной фабрике.

Чернышев Андрей Леонидович

Конечно, нет никакой "моей ОМД".

А как же дореляционная ОМД, которая без ООП? Вас что выперли с той тулсы, которую Вы раньше называли ОМД СУБД на платформе КАШи? Забыл как она называлась. Потом парни в той фирме перестали ее называть СУБД, а назвали какой-то там средой разработки или типа того.



mumps-ист

то Вам стоит просто помолчать?

ЧАЛ уже демонстративно уходил, потом уходил тока на 5 лет, типа раз в пять лет он приходит сюда убедиться в правильности выбора, который он сделал 30 лет назад. Потом появлялся под другими никами, но быстро выдавал себя ходом своих специфических рассуждений и лозунгами, которые он приготовил давно и повторяет - других у него нет. У него есть переодичность. Замолчит теперь не скоро - счас у него самый пик. Предположительно осеннее обострение.

Чернышев Андрей Леонидович

Так что мне УРА! так, видимо, и не доведется прокричать.

Ну ничего. Зато Вы сполна наотдавали низких поклонов в свое время своим клонам, которых понаделали в качестве группы поддержки Ваших взглядов.
6 ноя 06, 19:37    [3360388]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67427
Блог
Зл0й
Соответственно весь ораклячий ETL собран на хинтах, чтобы гарантировано работало.

Хм. Тут скорее подошли бы stored outlines, имхо.

Зл0й
Иначе если начнет тормозить - не расхлебаем. Просто не успеем - каждые 5 часов простоя это примерно терабайт накопившийся для обработки.

Хм. Я уважаю ваши объемы, но сугубо ради занудства - с точки зрения "не расхлебаем" они на самом деле значения не имеют. Значение имеют два фактора: резерв мощности и масштабируемость ETL (склонность [не] сохранять линейное время при росте входного объема). Ну и неравномерность входного объема по времени суток, если она есть. Скажем, если у вас предельная мощность 250 гигов в час, то пятичасовое опоздание вы нагоните за двадцать часов.
6 ноя 06, 23:03    [3360732]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 14 15 16 17 18 [19] 20 21 22 23 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить