Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 26 27 28 29 30 [31] 32 33 34 35 .. 106   вперед  Ctrl
 Re: Оффтоп, однако...  [new]
c127
Guest
Sergei Obrastsov
dekan
Вот читаю я это вот все и не могу понять -- а почему ЧАЛа еще не забанили... ведь оскорбления присутствуют однозначно.

Потому что и с противоположной стороны хватает хамства с избытком.

Вы бы сначала все-таки поинтересовались, кто начал хамить первым и как именно. Вот цитата из первого поста ЧАЛ-а на этом форуме. Приветствие, так сказать.
"Тогда будет (конечно, после дополнительных исследований) понятно, что реляционная модель стала шагом назад в теории баз данных, реляционные СУБД - шагом назад в практике применения технологий баз данных, я SQL практически бесполезен для доступа к данным."
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=9021&pg=14򭹰

А третий пост начинается словами:
"Уважаемые коллеги !

Обсуждение "технических вопросов" в такой форме абсолютно бесполезно - это объективная реальность.
"
и дальше чуть дальше:
"Потому что людям, использующим реляционные СУБД, очень трудно поверить в то, что SQL бесполезен, и я их прекрасно понимаю."
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=9021&pg=15#717354

Когда будете интересоваться хамством, то обратите заодно внимане на поучающий тон ЧАЛ-а.



Sergei Obrastsov

Все это верно. И ах, мне действительно придется изменять код, для того,
чтобы учесть появление или удаление индекса. И к сожалению, это решение
нельзя применить в 10 000 разных вариациях у различных пользователей.
Это специфическое решение конкретной задачи. Я и не пытался доказать
обратное. Но, в данном решении есть то, чего мне не даст РСУБД, а именно,
скорость поиска и компактность хранения данных. Более того, задача
фиксирована именно на этих данных и на других использоваться не будет
никогда, так что речь о добавлении/удалении индексов просто не идет.

В таком случае огласите пожалуйста эту самую конкретную задачу, может в РСУБД она решится вообще как-нибудь по-другому. Пока что Вы требуете чтобы РСУБД решение точно соответствовало Вашему решению на М, что не совсем корректно.
14 ноя 06, 03:50    [3395039]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
Sergei Obrastsov
DocAl
Sergei Obrastsov

Увы, оно выстрадано. Если Вы, конечно, не попытаетесь мне доказать
офигенную скорость работы Oracle на сотне миллионов записей с
указаными выше условиями без создания индексов. Машинку подсказать
для тестирования? P4-2,4/512/80
Интересный подход, однако: если оракл -- то без индексов, а каша -- так хоть десяток строй?

Во-первых, меня тут пытались убедить, что индексы фигня. Во-вторых,
боюсь что 9 индексов на 100 млн. записей + сами записи просто
не поместятся в 80 Gb.


create table TALKS.TTALKS_LOCAL_2005
(
p1 VARCHAR2(15),
p2 VARCHAR2(15),
p3 DATE not null,
p4 VARCHAR2(3),
p5 VARCHAR2(3),
p6 CHAR(1),
p7 NUMBER(6) not null,
p8 NUMBER(3),
p9 VARCHAR2(9),
p10 NUMBER(10),
p11 NUMBER(10),
p12 CHAR(1),
p13 NUMBER(4),
p14 NUMBER(4),
p15 NUMBER(10,2),
p16 NUMBER(2),
p17 NUMBER(20,5),
p18 NUMBER(20,5),
p19 DATE,
p20 NUMBER(2),
p21 VARCHAR2(4),
p22 NUMBER(3),
p23 NUMBER(3),
p24 NUMBER(10),
p25 VARCHAR2(15),
p26 VARCHAR2(22)
)

284 168 876 записей в таблице размер 18580 мб. индексы по 9 полям (по 3 типа varchar2(15), 2 по varchar2(3), 1 по varchar2(22), 1 по полю date, и 2 по полю типа number(3)) занимают 8014 мб.
Так что выши сомнения начсчет того что индексы и данные не поместяться в 80 Гб мягко говоря беспочвенны. Пример приведен из реальной биллинговой системы. Oracle 10G. Ваши жалкие 100 000 000 записей с 9 индексами Oracle прожует без особых проблем даже на диске вдвое меньшего объема. Если включить опцию COMPRESS для таблицы и индексов то можно еще больше сократить объем. Встречный вопрос сколько такое хозяйство в Каше места будет занимать. Или индексы в Каше вообще места не занимают ?
14 ноя 06, 03:50    [3395040]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
Виноват, первая ссылка такая:
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=9021&pg=14#712304
14 ноя 06, 03:54    [3395041]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Joker_Ya
284 168 876 записей в таблице размер 18580 мб. индексы по 9 полям (по 3 типа varchar2(15), 2 по varchar2(3), 1 по varchar2(22), 1 по полю date, и 2 по полю типа number(3)) занимают 8014 мб.
Так что выши сомнения начсчет того что индексы и данные не поместяться в 80 Гб мягко говоря беспочвенны. Пример приведен из реальной биллинговой системы. Oracle 10G.

Очень впечатляет. Особенно интересно, что в среднем на одну запись в одном
индексе приходится 3 байта. Я что-то путаю?
14 ноя 06, 04:35    [3395048]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
Sergei Obrastsov
Joker_Ya
284 168 876 записей в таблице размер 18580 мб. индексы по 9 полям (по 3 типа varchar2(15), 2 по varchar2(3), 1 по varchar2(22), 1 по полю date, и 2 по полю типа number(3)) занимают 8014 мб.
Так что выши сомнения начсчет того что индексы и данные не поместяться в 80 Гб мягко говоря беспочвенны. Пример приведен из реальной биллинговой системы. Oracle 10G.

Очень впечатляет. Особенно интересно, что в среднем на одну запись в одном
индексе приходится 3 байта. Я что-то путаю?


И что вас так впечатляет. Некоторые индексы созданы как bitmap index. Если интересно почитайте что это такое. Тогда поймете почему так. Кстати я просил привести пример как это в Каше реализовано. Я вам привел рабочий пример.
14 ноя 06, 04:43    [3395052]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
Sergei Obrastsov
Joker_Ya
284 168 876 записей в таблице размер 18580 мб. индексы по 9 полям (по 3 типа varchar2(15), 2 по varchar2(3), 1 по varchar2(22), 1 по полю date, и 2 по полю типа number(3)) занимают 8014 мб.
Так что выши сомнения начсчет того что индексы и данные не поместяться в 80 Гб мягко говоря беспочвенны. Пример приведен из реальной биллинговой системы. Oracle 10G.

Очень впечатляет. Особенно интересно, что в среднем на одну запись в одном
индексе приходится 3 байта. Я что-то путаю?


Сделал обычные индексы в виде B*Tree в другой схеме структура таблицы такая же но кол-во строк другое.
267 602 537 - 26686 мб (количество полей увеличилось соответствено вырос объем)
Индексы по тем же полям но ввиде B*Tree занимают 19576 мб
Даже в этом случае на данных боее чем в 2 раза превышающих ваши, объем базы даже близко не подошел к 80 Гб. Так что можете не сомневаться При использовании сжатия можно получить выигрыш процентов на 30-40 точно. Теперь всетаки хочеться увидеть пример от вас. А то слов много а конкретики мало.Цифры в студию а то словоблудие уже порядком надоело.
14 ноя 06, 05:17    [3395059]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Joker_Ya
[И что вас так впечатляет. Некоторые индексы созданы как bitmap index. Если интересно почитайте что это такое. Тогда поймете почему так. Кстати я просил привести пример как это в Каше реализовано. Я вам привел рабочий пример.

Что ж, принимается. Беру свои слова обратно насчет 80Gb :)
14 ноя 06, 05:18    [3395061]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Joker_Ya
Сделал обычные индексы в виде B*Tree в другой схеме структура таблицы такая же но кол-во строк другое.
267 602 537 - 26686 мб (количество полей увеличилось соответствено вырос объем)
Индексы по тем же полям но ввиде B*Tree занимают 19576 мб
Даже в этом случае на данных боее чем в 2 раза превышающих ваши, объем базы даже близко не подошел к 80 Гб. Так что можете не сомневаться При использовании сжатия можно получить выигрыш процентов на 30-40 точно. Теперь всетаки хочеться увидеть пример от вас. А то слов много а конкретики мало.Цифры в студию а то словоблудие уже порядком надоело.

Какие цифры? Скоко весит в граммах? Ладно: 120,179,976 строк по 116 байт
+ 9 индексов (ага, B*-Tree), из которых 6 - составные = 26.639 Gb.
14 ноя 06, 05:50    [3395070]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
Sergei Obrastsov
Joker_Ya
Сделал обычные индексы в виде B*Tree в другой схеме структура таблицы такая же но кол-во строк другое.
267 602 537 - 26686 мб (количество полей увеличилось соответствено вырос объем)
Индексы по тем же полям но ввиде B*Tree занимают 19576 мб
Даже в этом случае на данных боее чем в 2 раза превышающих ваши, объем базы даже близко не подошел к 80 Гб. Так что можете не сомневаться При использовании сжатия можно получить выигрыш процентов на 30-40 точно. Теперь всетаки хочеться увидеть пример от вас. А то слов много а конкретики мало.Цифры в студию а то словоблудие уже порядком надоело.

Какие цифры? Скоко весит в граммах? Ладно: 120,179,976 строк по 116 байт
+ 9 индексов (ага, B*-Tree), из которых 6 - составные = 26.639 Gb.


Если учесть что у меня данных в 2 раза больше то я думаю что на одном объеме данных результаты будут примерно одинаковые. А вот при использовании всех фич Оракла я могу уменьшить эти размеры как минимум на 30 %. Не написав ни одной строчки кода :) Возможно такое в Каше или кроме индексов в виде дерева там ничего больше нет ?
14 ноя 06, 07:01    [3395114]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Joker_Ya
Если учесть что у меня данных в 2 раза больше то я думаю что на одном объеме данных результаты будут примерно одинаковые. А вот при использовании всех фич Оракла я могу уменьшить эти размеры как минимум на 30 %. Не написав ни одной строчки кода :) Возможно такое в Каше или кроме индексов в виде дерева там ничего больше нет ?

Размер исходной записи можете сказать? Это я к тому, что есть разница иметь в исходной строке 50 байт и 100, к примеру. Если схема compress не изменилась, то на телефонных разговорах вряд ли удастся поджать на 30%,
мало совпадающих значений в одном блоке. Хоть Cache и не позволяет такого сжатия системным путем, я могу в данной задаче достигнуть не менее серьезных результатов, во-первых, за счет удаления избыточных данных, существующих в индексах, во-вторых, за счет сжатия самой строки данных. В этом случае можно нагнать до 40%. Но это, конечно, мелочи. Официально кроме деревьев ничего нет.
14 ноя 06, 07:50    [3395150]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
Sergei Obrastsov
Joker_Ya
Если учесть что у меня данных в 2 раза больше то я думаю что на одном объеме данных результаты будут примерно одинаковые. А вот при использовании всех фич Оракла я могу уменьшить эти размеры как минимум на 30 %. Не написав ни одной строчки кода :) Возможно такое в Каше или кроме индексов в виде дерева там ничего больше нет ?

Размер исходной записи можете сказать? Это я к тому, что есть разница иметь в исходной строке 50 байт и 100, к примеру. Если схема compress не изменилась, то на телефонных разговорах вряд ли удастся поджать на 30%,
мало совпадающих значений в одном блоке. Хоть Cache и не позволяет такого сжатия системным путем, я могу в данной задаче достигнуть не менее серьезных результатов, во-первых, за счет удаления избыточных данных, существующих в индексах, во-вторых, за счет сжатия самой строки данных. В этом случае можно нагнать до 40%. Но это, конечно, мелочи. Официально кроме деревьев ничего нет.


Ошибаетесь при использовании Bitmap индекса его размер меньше не на 40 процентов а в 3-5 раз. Как раз на разговорах повторяющихся данных масса например номера телефонов, коды направлений, мнемоники. Проверено на реальных данных. Кстати при использовании bitmap индексов скорость запросов увеличилась значительно за счет многократного уменьшения объема индекса.Насчет сжатия данных. Мне для этого ничнго делать не надоэто сервер сам позволяет делать как и все остальное. За это платят деньги. Кстати за Каше просят такие же деньги как и за Оракл только в нем все надо ручками делать. Вопрос за что просят такие же деньги как и за оракл? Такой вопрос однажды был задан на семинаре InterSystem ответа внятного не получили. Одни маркетинговые лозунги что типа пост реляционная и т д. Я не против Каше я против того что эту подделку пытаются всунуть людям за нехилое бабло.
14 ноя 06, 08:10    [3395172]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Joker_Ya
Ошибаетесь при использовании Bitmap индекса его размер меньше не на 40 процентов а в 3-5 раз.

Дался Вам этот bitmap. Про compress разговор шел вообще-то.

Joker_Ya

А вот при использовании всех фич Оракла я могу уменьшить эти размеры как минимум на 30 %.

Ваша фраза? Или я опять передергиваю?

Joker_Ya

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

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

P.S. Так что все-таки с размером исходной строки?
14 ноя 06, 08:49    [3395239]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
Sergei Obrastsov
Joker_Ya
Ошибаетесь при использовании Bitmap индекса его размер меньше не на 40 процентов а в 3-5 раз.

Дался Вам этот bitmap. Про compress разговор шел вообще-то.

Joker_Ya

А вот при использовании всех фич Оракла я могу уменьшить эти размеры как минимум на 30 %.

Ваша фраза? Или я опять передергиваю?

Joker_Ya

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

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

P.S. Так что все-таки с размером исходной строки?


По поводу COMPRESS данная опция упаковывает данные в блоках. Если честно в подробности реализации не вдавался но у меня на таблице которую я вам приводил сокращение объема составляет от 30-50 %. Интересно узнать подробности добро пожаловать на oracle.com там масса статей про это. Размер строки можете сами посчитать я вам структуру таблицы дал.
Кодировку использую однобайтную. Так что грубо говоря 1 символ 1 байт.
Примерно 219 байт (поля типа Date я считал 10 символов, если честно не знаю точно как там оно все внутри храниться, структура файла данных у Оракла не очень простая). Пусть в среднем заполнение данными составляет 70% от максимального объема.
14 ноя 06, 10:06    [3395534]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
kvasov
Gluk (Kazan)
Sergei Obrastsov
^dft(date)=count
^dft(date,"idx",idx)=v1~v2~v3~v4~v5~v6~v7...v18
^dft(date,"tr",v1)=count
^dft(date,"tr",v1,idx)=
^dft(date,"cat",v2)=count


Жесть :(
И поля в ключе индекса я так понимаю тильдачками разделены ?


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

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


Сейчас нет времени комментировать, но картинки можно больше не рисовать я все прекрасно понял. Это ЖЕСТЬ для любого РСУБД-ника. Развернуто объяснять почему времени сейчас нет.

Тема для размышления: Нормализация
Тема нумбер 2: автоматическая поддержка контроля целостности
14 ноя 06, 10:14    [3395588]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
~
Guest
Sergei Obrastsov
Задача - минимизировать время поиска, заданных одновременно или по отдельности v1-v6, v15-v18 в структуре. Остальные данные не позволяют индексирования, либо по причине их большой дискретности,
либо по причине редкого использования. Объем, занимаемый данными,
конечно, критичен, но рассматриваться не будет.
14 ноя 06, 11:29    [3396277]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
мод
Guest
Gluk (Kazan)
Это ЖЕСТЬ для любого РСУБД-ника.

Это ЖЕСТЬ для любой СУБД. Но М - это не СУБД, это инструмент для работы с простыми индексно-последовательными файлами со всеми вытекающими. Все непонимание из-за того, что сравниваются несравнимые вещи.
14 ноя 06, 12:11    [3396679]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Gluk (Kazan)
Это ЖЕСТЬ для любого РСУБД-ника.
Развернуто объяснять почему времени сейчас нет.


И что с того ?
Для С++ ЖЕСТь это код на басике и что дальше.

Можете кстати и не объяснять.
Кашёвцам и мупсерам "ужос" РСУБД-ников как то по барабану, они РСУБД-никами не являются.
14 ноя 06, 12:21    [3396775]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Gluk (Kazan)

Тема для размышления: Нормализация
Тема нумбер 2: автоматическая поддержка контроля целостности


1. Какие то проблемы ? Требование нормализации озвучьте.

2. Всё в руках ваших. Отношения автоматом.
14 ноя 06, 12:25    [3396820]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2405
Блог
мод
Это ЖЕСТЬ для любой СУБД. Но М - это не СУБД, это инструмент для работы с простыми индексно-последовательными файлами со всеми вытекающими. Все непонимание из-за того, что сравниваются несравнимые вещи.
Так именно это всем мироам мампсистам тут пытаются объяснить, а они - ни в какую!
14 ноя 06, 12:42    [3396966]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
мод
Guest
Павел Воронцов
Так именно это всем мироам мампсистам тут пытаются объяснить, а они - ни в какую!

Они просто с ISAMом не работали, сразу на диамс перешли :)
14 ноя 06, 12:59    [3397132]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
мод
Но М - это не СУБД, это инструмент для работы с простыми индексно-последовательными файлами со всеми вытекающими.

Значит в Oracle - это крутые IOT, а в M - "простые индексно-последовательные файлы"? Забавно.
14 ноя 06, 13:25    [3397338]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov
мод
Но М - это не СУБД, это инструмент для работы с простыми индексно-последовательными файлами со всеми вытекающими.

Значит в Oracle - это крутые IOT, а в M - "простые индексно-последовательные файлы"? Забавно.


В Oracle ПОМИМО IOT еще много чего есть. А перевести ВСЕ на IOT ни одному ораклоиду в голову не придет.

Коль пошла такая пьянка, как реализуется ACID в M ? Кооперативными блокировками ???

В одном ЧАЛ прав, Cache не иерархическая СУБД. Это вообще непойми что :(
14 ноя 06, 13:44    [3397504]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
мод
Guest
Sergei Obrastsov
Забавно.

Нам всем тоже :)
14 ноя 06, 14:15    [3397808]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
softwarer
Пожалуйста - 116 байт.

С цифрами Вам уже ответили.

softwarer
Использование записи в качестве ключа я не считаю адекватным ответом, это несерьезно.

Опять же не понял.

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

Типичный случай поиска, я бы сказал - поиск по набору критериев, каждый из которых не особо селективен.

Sergei Obrastsov
Не затруднит сделать тынц на цитату?

тынц

Хм. Наверное, это из серии непонимания. На вопрос "вы обещали таблицу" Вы получили таблицу, имхо в чем-то логично.

Не забывайте, что для РСУБДшника индекс - объект физического уровня, отделенный от уровня логического. Когда речь идет "как сделать структуру для этой задачи", индексы не пишут. Их пишут, отвечая на следующий вопрос: "как сделать чтобы оно быстро работало" (это, конечно, изрядное упрощение, но все же).
14 ноя 06, 14:49    [3398073]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kvasov
Member [заблокирован]

Откуда:
Сообщений: 853
Joker_Ya

create table TALKS.TTALKS_LOCAL_2005
(
p1 VARCHAR2(15),
p2 VARCHAR2(15),
p3 DATE not null,
p4 VARCHAR2(3),
p5 VARCHAR2(3),
p6 CHAR(1),
p7 NUMBER(6) not null,
p8 NUMBER(3),
p9 VARCHAR2(9),
p10 NUMBER(10),
p11 NUMBER(10),
p12 CHAR(1),
p13 NUMBER(4),
p14 NUMBER(4),
p15 NUMBER(10,2),
p16 NUMBER(2),
p17 NUMBER(20,5),
p18 NUMBER(20,5),
p19 DATE,
p20 NUMBER(2),
p21 VARCHAR2(4),
p22 NUMBER(3),
p23 NUMBER(3),
p24 NUMBER(10),
p25 VARCHAR2(15),
p26 VARCHAR2(22)
)



да, но где накопительные итоги по 5 полям к примеру хранить?
правильно - в 5 новых табличках
и в каждой из 5 табличек по ключевому индексу
итого имеем:
1 родительскую табличку
1 родительский ключевой индекс
5 дочерних табличек
5 дочерних индексов
------------------------
Итого: 6 табличек + 6 индексов

И это эквиваленто - 1 глобалу Каше - во и вся разница между ораклом и каше.

могут быть задачи, где лучше использовать преимущества оракл? - могут
могут быть задачи, где лучше использовать преимущества каше? - могут

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

а "рсубд-шники" чего-то доказывают, доказывают . . . ЧАЛ-у, но он уехал в командировку, и работает с обьектами, а мумпстеры с обьектами не работают.
14 ноя 06, 16:18    [3398739]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 26 27 28 29 30 [31] 32 33 34 35 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить