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

Откуда: Магадан
Сообщений: 584
kvasov
тильды изображают хранящуюся, как рассказывают, теговую структуру (до 32k)

Не понимаю, причем тут теги-то? ~ просто разделители полей в одной строке данных. Я мог бы выбрать любой другой символ или группу символов, хоть CHAR(0) :)
13 ноя 06, 17:46    [3393754]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
Sergei Obrastsov
Я, правда, действительно
не понимаю каким образом Вы умудритесь вставить 10 раз одни и те же
значения в primary key и, главное, зачем, но это уже мелочи, конечно.

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

Я без проблем возьму табличку SergSuper и повешу на нее пользовательский индекс, который будет держать десять указанных Вами вариантов поиска (или сколько их там нужно). При этом программист, добавляющий данные, не будет вынужден думать о записи их в индекс; я могу добавить индекс и весь ранее написанный код не придется дорабатывать. При этом те, кто вызывает поиск, не будут вынуждены думать про структуру хранения и модифицировать код каждый раз, когда я оптимизирую структуру. Если я убью индекс, пользовательский код не развалится, всего лишь станет искать медленнее. Мало того, этот индекс можно будет применить к любой таблице, примерно как подпрограмму.

Обладает ли приведенное Вами решение теми же достоинствами?
13 ноя 06, 17:47    [3393767]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
точно, можно 10 раз и не вставлять, а делать например вычисляемые поля и на них повесить индексы
это и при той же структуре таблице из двух полей!
13 ноя 06, 18:06    [3393921]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
softwarer
Я без проблем возьму табличку SergSuper и повешу на нее пользовательский индекс, который будет держать десять указанных Вами вариантов поиска (или сколько их там нужно).

Что Вы в данном случае понимаете под пользовательским индексом? Мне
действительно интересно на это взглянуть. Равно как и на код для поиска
по предложенным условиям.

softwarer

При этом программист, добавляющий данные, не будет вынужден думать о записи их в индекс; я могу добавить индекс и весь ранее написанный код не придется дорабатывать. При этом те, кто вызывает поиск, не будут вынуждены думать про структуру хранения и модифицировать код каждый раз, когда я оптимизирую структуру. Если я убью индекс, пользовательский код не развалится, всего лишь станет искать медленнее. Мало того, этот индекс можно будет применить к любой таблице, примерно как подпрограмму.
Обладает ли приведенное Вами решение теми же достоинствами?

Все это верно. И ах, мне действительно придется изменять код, для того,
чтобы учесть появление или удаление индекса. И к сожалению, это решение
нельзя применить в 10 000 разных вариациях у различных пользователей.
Это специфическое решение конкретной задачи. Я и не пытался доказать
обратное. Но, в данном решении есть то, чего мне не даст РСУБД, а именно,
скорость поиска и компактность хранения данных. Более того, задача
фиксирована именно на этих данных и на других использоваться не будет
никогда, так что речь о добавлении/удалении индексов просто не идет.
13 ноя 06, 18:07    [3393927]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SergSuper
точно, можно 10 раз и не вставлять, а делать например вычисляемые поля и на них повесить индексы
это и при той же структуре таблице из двух полей!

Простите за глупый вопрос, но индексы вешать на эти "вычисляемые" поля
Вы собираетесь во время выполнения запроса, я не ошибаюсь?
13 ноя 06, 18:08    [3393939]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
МХ -- ALEX
Guest
softwarer
Sergei Obrastsov
Я, правда, действительно
не понимаю каким образом Вы умудритесь вставить 10 раз одни и те же
значения в primary key и, главное, зачем, но это уже мелочи, конечно.

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

Я без проблем возьму табличку SergSuper и повешу на нее пользовательский индекс, который будет держать десять указанных Вами вариантов поиска (или сколько их там нужно). При этом программист, добавляющий данные, не будет вынужден думать о записи их в индекс; я могу добавить индекс и весь ранее написанный код не придется дорабатывать. При этом те, кто вызывает поиск, не будут вынуждены думать про структуру хранения и модифицировать код каждый раз, когда я оптимизирую структуру. Если я убью индекс, пользовательский код не развалится, всего лишь станет искать медленнее. Мало того, этот индекс можно будет применить к любой таблице, примерно как подпрограмму.

Обладает ли приведенное Вами решение теми же достоинствами?


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

думаю принципиальной разницы с реляционными нет
- вопрос в привычках и деталях
но если задача с большой вероятностью не будет меняться
- или меняться раз в 5 лет - на производстве это как правило -
у нас есть задачи и по 20 лет - и прекрасно и быстро работают -
то решение Образцова очень неплохое - сразу включает всю
теоретически достижимую скорость поиска
на наиболее вероятных запросах .

но если справочная железнодорожной кассы
заточена на набор стандартных запросов
то
"а в каком вагоне сегодня работает проводница Надя"
заставит систему напрячься что у Вас что у нас в M
13 ноя 06, 18:23    [3393998]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kvasov
Member [заблокирован]

Откуда:
Сообщений: 853
Sergei Obrastsov
kvasov
тильды изображают хранящуюся, как рассказывают, теговую структуру (до 32k)

Не понимаю, причем тут теги-то? ~ просто разделители полей в одной строке данных. Я мог бы выбрать любой другой символ или группу символов, хоть CHAR(0) :)


ну я имел ввиду, что если использовать фукцию ListBuild, то и разделителей не надо, у нее там вместо разделителей свои теги, самому их делать конечно не надо, а то Gluk подумает что надо обязательно тильды делать.
13 ноя 06, 18:23    [3393999]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
Sergei Obrastsov
Что Вы в данном случае понимаете под пользовательским индексом?

Хм. Я понимаю, что мы обсуждали это уже достаточно давно, но все же
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=16&hl=indextype#3338310

Sergei Obrastsov
Равно как и на код для поиска по предложенным условиям.

Обычный SQL.

Sergei Obrastsov
softwarer

Обладает ли приведенное Вами решение теми же достоинствами?

Все это верно. ....

Хм. Странный ответ на вопрос "обладает ли" :)

Sergei Obrastsov
Это специфическое решение конкретной задачи. .... Более того, задача фиксирована именно на этих данных и на других использоваться не будет никогда.

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

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

Sergei Obrastsov
Я и не пытался доказать обратное. Но, в данном решении есть то, чего мне не даст РСУБД, а именно, скорость поиска и компактность хранения данных.

Это утверждение несколько умозрительно.

Что касается компактности, это само по себе не достоинство. Скажем, что Вы будете делать, если окажется, что пользователя чаще всего интересует поле v12, в то время как поле v6 очень велико по размеру? Если я правильно понимаю, Вам придется либо смириться с постоянным хождением к v12 мимо v6, либо опять-таки перерабатывать код.

Что касается скорости поиска, с ней все элементарно: для любого заранее определенного набора критериев можно сделать поиск максимально быстрым. В последние годы РСУБД-шников куда больше интересует другая задача, а именно ad-hoc запросы, поиск по заранее неизвестным критериям.
13 ноя 06, 18:33    [3394024]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kvasov
Member [заблокирован]

Откуда:
Сообщений: 853
softwarer
В последние годы РСУБД-шников куда больше интересует другая задача, а именно ad-hoc запросы, поиск по заранее неизвестным критериям.


интересно, приведите пример, если можно
13 ноя 06, 18:43    [3394054]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
kvasov
интересно, приведите пример, если можно

Не понял, пример чего именно. Произвольного запроса?

Пользователю дается тот или иной инструмент, с помощью которого он управляет критериями отбора данных. Самый примитивный вариант - QBE.
13 ноя 06, 18:48    [3394075]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
softwarer
Не бывает программистов, которые год за годом решают уникальные, неповторяющиеся задачи.

Прошу прощения, пропустил пару слов.

Не бывает программистов, которые год за годом решают только и исключительно уникальные, неповторяющиеся задачи.
13 ноя 06, 18:50    [3394085]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Sergei Obrastsov
SergSuper
точно, можно 10 раз и не вставлять, а делать например вычисляемые поля и на них повесить индексы
это и при той же структуре таблице из двух полей!

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

Это можно делать при создании таблицы или потом при возникновении необходимости. Запросы в это время могут работать.
13 ноя 06, 19:12    [3394179]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
мод
Зл0й
Имеем вывод: для любой модели данной представляющей собой граф (иерархическая, сетевая, всяческие мампсы), существует эквивалентное ей реляционное представление.

Это верно, только отношение будет в общем случае ненормализованное.

Ну и что, мали что ли денормализованных таблиц на свете? У меня в Data Warehouse - навалом.
13 ноя 06, 19:57    [3394337]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
softwarer
Все, кроме разве что безнадежных кодеров, вырабатывают некоторые стандартные решения. И если это стандартное решение не может быть реализовано стандартным же кодом - это серьезный недостаток технологии.

Смотря что называть "стандартным решением". Если это сование SQL в каждую
дырку, то я предпочитаю нестандартные решения.

softwarer

Sergei Obrastsov
Я и не пытался доказать обратное. Но, в данном решении есть то, чего мне не даст РСУБД, а именно, скорость поиска и компактность хранения данных.

Это утверждение несколько умозрительно.

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

Sergei Obrastsov

Что касается компактности, это само по себе не достоинство. Скажем, что Вы будете делать, если окажется, что пользователя чаще всего интересует поле v12, в то время как поле v6 очень велико по размеру? Если я правильно понимаю, Вам придется либо смириться с постоянным хождением к v12 мимо v6, либо опять-таки перерабатывать код.

Вы даже не стараетесь вникнуть. Я бы, например, переспросил для верности. Поскольку я храню и поле v6, и поле v12, и оба индексированы, то какая фиг разница, к какому из них обращаются чаще? Под компактностью имеется
в виду именно компактность хранения данных, не больше и не меньше.
Насчет переработки кода - задача логически закончена. В ней естественно
обрабатываются все существующие 18 полей.

Sergei Obrastsov

Что касается скорости поиска, с ней все элементарно: для любого заранее определенного набора критериев можно сделать поиск максимально быстрым. В последние годы РСУБД-шников куда больше интересует другая задача, а именно ad-hoc запросы, поиск по заранее неизвестным критериям.

Как я уже сказал, это реализовано. Не поверю, что бы Вы догадались
индексировать время в секундах. Это я к неизбежному вопросу, а почему
не все индексировано. :)
13 ноя 06, 20:51    [3394491]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
softwarer
Не бывает программистов, которые год за годом решают только и исключительно уникальные, неповторяющиеся задачи.

Значит я такой везучий. Поскольку за последние 10 лет все задачи у меня
уникальные и уж точно не повторяются. Для повторяющихся и не уникальных
есть отдел IT в составе 15 человек с MSSQL наперевес.
13 ноя 06, 20:55    [3394501]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Sergei Obrastsov

Увы, оно выстрадано. Если Вы, конечно, не попытаетесь мне доказать
офигенную скорость работы Oracle на сотне миллионов записей с
указаными выше условиями без создания индексов. Машинку подсказать
для тестирования? P4-2,4/512/80
Интересный подход, однако: если оракл -- то без индексов, а каша -- так хоть десяток строй?
13 ноя 06, 21:06    [3394523]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

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

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

Во-первых, меня тут пытались убедить, что индексы фигня. Во-вторых,
боюсь что 9 индексов на 100 млн. записей + сами записи просто
не поместятся в 80 Gb.
13 ноя 06, 21:20    [3394557]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Sergei Obrastsov

Во-первых, меня тут пытались убедить, что индексы фигня. Во-вторых,
боюсь что 9 индексов на 100 млн. записей + сами записи просто
не поместятся в 80 Gb.
Ну уж это-то ограничение сугубо искусственное. Месяц назад мне нужно было в офисной машине винт заменить, как раз 80 гиговый. Обошёлся он мне что-то в 1100 рублей, что ли.

Про незначительность индексов говорили лишь в том плане, что SQL решение от отсутствия индексов проиграет в скорости, но останется работоспособным. Индексы не являются неотъемлимой частью решения, а только его оптимизацией. Забавно, но выходит, именно SQL в этом случае оказывается более гибким.
13 ноя 06, 21:39    [3394595]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
[quot softwarer. Не бывает программистов, которые год за годом решают уникальные, неповторяющиеся задачи.

Все, кроме разве что безнадежных кодеров, вырабатывают некоторые стандартные решения. И если это стандартное решение не может быть реализовано стандартным же кодом - это серьезный недостаток технологии.
.[/quot]
мой коллега на другом конце Земли г-н Образцов
пишет на M уникальные и дорогие программы
мы - наоборот - гоним вал

я уже упоминал нашу M-систему - по функциям вполне заменяет
1-с и внедрена более чем на сотне ну очень разных предприятий
и учреждений - без модификации м-кода !
куда уж стандартнее..
так что, по-моему, дело не в модели данных
13 ноя 06, 21:47    [3394608]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
DocAl
Ну уж это-то ограничение сугубо искусственное. Месяц назад мне нужно было в офисной машине винт заменить, как раз 80 гиговый. Обошёлся он мне что-то в 1100 рублей, что ли.

Это фактическое ограничение. Я не буду тратить собственные деньги и без
того не огромные на то, что должна делать организация. А ее эти мелочи не
волнуют. Так что это - данность и с этим приходится считаться.

DocAl

Про незначительность индексов говорили лишь в том плане, что SQL решение от отсутствия индексов проиграет в скорости, но останется работоспособным. Индексы не являются неотъемлимой частью решения, а только его оптимизацией. Забавно, но выходит, именно SQL в этом случае оказывается более гибким.

Я никогда и не спорил с этим. Но бывают и ситуации когда общее решение
заведомо проигрышнее частного. Как в этом случае, с объемом
хранимых данных, например. Боюсь, что со скоростью дело будет обстоять
тоже не лучшим образом, хотя честно скажу, проверить возможности нет.
13 ноя 06, 22:03    [3394635]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
Sergei Obrastsov
Смотря что называть "стандартным решением". Если это сование SQL в каждую дырку, то я предпочитаю нестандартные решения.

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

Sergei Obrastsov
Увы, оно выстрадано. Если Вы, конечно, не попытаетесь мне доказать офигенную скорость работы Oracle на сотне миллионов записей с
указаными выше условиями без создания индексов.

Нда. Передергивание цветет и пахнет. Неужели Cache больше нечем защищать?

Sergei Obrastsov
Вы даже не стараетесь вникнуть. Я бы, например, переспросил для верности.

Я еще понимаю, когда Вы "не помните" того, что говорилось десять страниц назад. Но когда Вы предпочитаете не заметить "переспроса для верности" в том же предложении, на которое отвечаете - это уже за пределами моего понимания.

Sergei Obrastsov
Поскольку я храню и поле v6, и поле v12, и оба индексированы,

Боюсь, я не увидел в Вашем коде индекса по v12. Не затруднит ли ткнуть пальцем?

Sergei Obrastsov
то какая фиг разница, к какому из них обращаются чаще? Под компактностью имеется в виду именно компактность хранения данных,

И я об этом же.

Sergei Obrastsov
Как я уже сказал, это реализовано.

Да. Вы сказали - как основной плюс - что реализован быстрый доступ по фиксированным критериям поиска. Во всяком случае, я так Вас понял. Меня, признаться, это выдающееся достижение не впечатляет; слишком редки системы, где такого нет.

Sergei Obrastsov
Не поверю, что бы Вы догадались индексировать время в секундах. Это я к неизбежному вопросу, а почему не все индексировано. :)

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

Sergei Obrastsov
Во-первых, меня тут пытались убедить, что индексы фигня.

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

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

Хм. Бояться, конечно, можно всего, но стоит ли? 80 Gb и 100 млн. записей - это совершенно бесполезные цифры. Добавьте к ним ширину данных - объем записи в байтах - и узнаем.
14 ноя 06, 00:40    [3394938]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
Sergei Obrastsov
Значит я такой везучий. Поскольку за последние 10 лет все задачи у меня уникальные и уж точно не повторяются.

Ну-ну.

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

Признаться, напоминает.
14 ноя 06, 00:42    [3394942]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
softwarer
Sergei Obrastsov
Смотря что называть "стандартным решением". Если это сование SQL в каждую дырку, то я предпочитаю нестандартные решения.

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

А разве речь не шла о SQL как о "стандартном решении"? Тогда прошу прощения, конечно. Я так понял, что Вы имели в виду именно это.

softwarer

Sergei Obrastsov
Увы, оно выстрадано. Если Вы, конечно, не попытаетесь мне доказать офигенную скорость работы Oracle на сотне миллионов записей с
указаными выше условиями без создания индексов.

Нда. Передергивание цветет и пахнет. Неужели Cache больше нечем защищать?

Вы усомнились, я ответил. Или Вы про индексы? Так они не влезут просто
в указанный объем.

softwarer

Sergei Obrastsov
Вы даже не стараетесь вникнуть. Я бы, например, переспросил для верности.

Я еще понимаю, когда Вы "не помните" того, что говорилось десять страниц назад. Но когда Вы предпочитаете не заметить "переспроса для верности" в том же предложении, на которое отвечаете - это уже за пределами моего понимания.

Каюсь, поторопился. Иногда желаемое занимает место действительного. :)
Sorry

softwarer

Sergei Obrastsov
Поскольку я храню и поле v6, и поле v12, и оба индексированы,

Боюсь, я не увидел в Вашем коде индекса по v12. Не затруднит ли ткнуть пальцем?

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

softwarer

Sergei Obrastsov
Как я уже сказал, это реализовано.

Да. Вы сказали - как основной плюс - что реализован быстрый доступ по фиксированным критериям поиска. Во всяком случае, я так Вас понял. Меня, признаться, это выдающееся достижение не впечатляет; слишком редки системы, где такого нет.

Я вообще-то и не пытался кого-то впечатлить, речь шла о многомерном дереве
и о его аналоге в реляционной БД. Вот аналог как раз не впечатлил меня,
я сомневаюсь в его адекватности.

softwarer

Sergei Obrastsov
Не поверю, что бы Вы догадались индексировать время в секундах. Это я к неизбежному вопросу, а почему не все индексировано. :)

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

Это так, мысли вслух.

Sergei Obrastsov
Во-первых, меня тут пытались убедить, что индексы фигня.

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

тынц

Во всяком случае у меня возникло именно такое ощущение.

softwarer

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

Хм. Бояться, конечно, можно всего, но стоит ли? 80 Gb и 100 млн. записей - это совершенно бесполезные цифры. Добавьте к ним ширину данных - объем записи в байтах - и узнаем.

Пожалуйста - 116 байт. Использование записи в качестве ключа я не считаю
адекватным ответом, это несерьезно.
14 ноя 06, 01:26    [3394979]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
softwarer
Sergei Obrastsov
Значит я такой везучий. Поскольку за последние 10 лет все задачи у меня уникальные и уж точно не повторяются.

Ну-ну.

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

Признаться, напоминает.

Что ж, хороший пример ответного передергивания. Молодца! :)
Впрочем, я не собираюсь оправдываться, это будет уже смешно.
14 ноя 06, 01:31    [3394985]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
jekaSQL
Member

Откуда: Бабруйск
Сообщений: 596
Sergei Obrastsov
Увы, оно выстрадано. Если Вы, конечно, не попытаетесь мне доказать офигенную скорость работы Oracle на сотне миллионов записей с
указаными выше условиями без создания индексов.


не совсем понятно, почему оракля должен работать на сотне миллионов записей без индексов, создаваемых парой движений мышки, а каше с индексами, причем созданными вручную упорным трудом программистов?


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

Если бы все так просто было. Поля еще надо добавлять и обновлять, и если по ним есть индекс, то это совсем не бесплатно.


Sergei Obrastsov
Во-первых, меня тут пытались убедить, что индексы фигня.

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

тынц
[/quot]

А где же там индексы???

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


Иногда кажется, что вы бредите... Какие записи, какие индексы? Почему 9? Какой тип данных? 9 индексов по int влезут в пяток гигов.

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

Это о чем?
14 ноя 06, 02:30    [3395014]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 25 26 27 28 29 [30] 31 32 33 34 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить