Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 19   вперед  Ctrl
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
S.G.
Скорость СУБД тут, имхо, последнее дело. Не знаю, знаком ли автор с проблемами машинного перевода. И в частности, с неоднозначностями естественных языков. У меня тут статья, линк к которой я в инете, к сожалению, не нашел, поэтому, просто перепишу пару абзацев:
1. "лексикальная" неоднозначность. слово имеет более одного значения. Например, "Stay away from the bank", может означать совет инвестору стоять подальше от банка, или совет ребенка стоять подальше от берега.
2. "структурная" неоднозначность. - неоднозначность скрыта в комбинации слов. Например: "He saw that gasoline can explode" - "Он увидел, что бензин может взорваться", или "он увидел, что тот бидон с бензином взорвался".
3. "глубинная неоднозначность". Два предложения могут иметь одну и ту же грамматическую структуру, но иметь разный смысл. Например: "The chickens are ready to eat". Понятно что кто-то готов съесть что-то, но цыплята здесь- это кто-то или что-то?
И так далее, пять типов неоднозначностей.
Кроме того, при реальных переводах никогда не переводится дословно. некоторые слова могут выпасть, другие- добавиться. Кто- то поставит лишний пробел, запятую и т.д
Все это может привести к тому, что на каждое предложение будет выдано несколько десятков, а может и сотня вариантов, включая ошибочные, включая скажем и те в которых кириллическая буква "а" заменена латинской буквой "a". И может оказаться что хорошему переводчику легче перевести самому, а средние и плохие будут заполнять базу плохими переводами.

Ну, а так, конечно, всяческих успехов :)



Вот это все будет учитывать программа. Только она не будет вдаватся в смысл предложений, а будет использовать статистику. Она будет хранить все варианты переводов, которые когда либо будут вносится Пользователями.
Например:
This is a computer - Булочная есть сегодня быТь закрыт.

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

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

1. Например, исходный текст нужно будт привести в нормальный текстовой формат, а после разбить его на абзацы, предложения, слова и разделительные знаки.
2. По словам и фразам нужно будет определить тематику более вероятную.
3. Составить план перевода каждого предложения. (Тут очень много сложностей)
4. Выбрать наиболее подходящие слова по оценочной функции и сделать перевод.
5. Дать самому пользователю внести необхдимые измнения как в оригинале так и в переводе и все пустить по новой.
6 май 06, 08:19    [2637848]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
Victor Metelitsa
Sergei Obrastsov
Интересно было бы узнать источник этой информации. :)
Фактически, Cache хранит эти же данные МИНИМУМ в 2 раза меньшим
объемом. Ну, например, 15,000,000 записей в MS SQL занимают 3.5 Gb
(19 полей переменной длины). Cache в этом объеме умещает 30,000,000
таких записей + 240,000,000 дополнительных индексов для быстрой
выборки. Сергей

Каким же образом это возможно? У Кэшэ байт из 16 битов?

Нет, у каше технология сжатия ключей ;-)
6 май 06, 08:30    [2637861]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
автор
6 май 06, 08:34    [2637869]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
У меня еще один вопрос.

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

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

Эту вещь можно написать на JavaScript, но есть одно но. Для каждого предложения нужно будет передавать всю служебную информацию. А это будет очень много если текст большой.

Можно ли сделать красиво на базе SQL 2005, Oracle, Cache, что когда пользователь выделяет одно предложение, то web страничка отправляет запрос, получает всю необходимую инфу по оригиналу и переводу предложения и сама выделяет переведенное предложение, но без перегрузки всей страницы?
6 май 06, 08:36    [2637873]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Несколько реплик и вопросов.
lura
TMDM снимает все ограничения, накладываемые двумерными реляционными моделями данных, ведь если реляционная модель состоит из большого количества таблиц, что необходимо при работе со сложными структурами данных, это существенно усложняет и замедляет выполнение сложных транзакций и ведет к хранению излишней информации.

Двумерные реляционные таблицы используют простую для понимания математическую модель, пригодную для достаточно простых приложений и запросов. Однако, в реальной ситуации представляемая в базе данных информация многомерна
Безграмотная писанина. Фраза «двумерными реляционными моделями данных» говорит о многом. Во-первых, писавший уверен, что реляционных моделей данных много. Во-вторых, он думает, что к понятию «модель данных» приложимо понятие «измерение/размерность». И при этом РМД почему-то именно двумерная. Автор непостижимым образом уверен, что количество таблиц каким-то образом влияет на транзакции. Что «большое количество таблиц» ведет к «хранению излишней информации».
Фраза про «двумерные»/«плоские» реляционные таблицы вообще традиционный показатель слабого понимания. Да, физически нарисованная на бумаге таблица — плоская, потому, что плоский лист бумаги. Но логическая R-таблица, а точнее отношение вообще не имеет измерений, ни двух, ни одного, ни двухсот. И, кстати, если уж приспичит говорить про многомерность, то кортежи отношения с N атрибутами представляют точки N-мерного пространства. Говорить же, что «информация многомерна» — в общем случае бессмыслица. Короче, несмотря на утверждение про «простую для понимания математическую модель», для авторов она оказалась слишком сложной, не осилили.

Sergei Obrastsov
теперь о деревьях. в принципе, "реляционные модели" - тоже деревья. Только двухуровневые. поэтому не надо ахать "ой, 2 или n деревьев", в РСУБД та же фигня. :)

Sergei Obrastsov
таблицы легко представляются в "деревьях", первый уровень - индекс, второй - номер записи. почему "дерево"? потому что похоже на елку, если нарисовать (особенно отношение "1:any"). :) почему только два уровня? потому что такие таблицы, там только одно отношение. если индекс составной, то он скомбинирован. так он выглядит логически, так он сделан и физически. за исключением исходных данных, там только один уровень (номер записи)
Читая эти вещи так ничего и не понял. Ведь в отношениях нет ни индексов, ни номеров записей. Не могли бы вы изложить свою мысль более формально? Для начала пояснить, что вы понимаете под деревом? Если это то, что понимается в математике (теории графов), то опишите строгое соответствие между понятиями из РМД (домен, атрибут, кортеж, отношение) и из теории графов (вершина, ребро). Сразу станет ясна ваша мысль.
Укажу лишь, что в таком аспекте любое дерево и вообще любой граф представляется одним отношением (таблицей смежности).
6 май 06, 09:10    [2637927]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
tygra
автор
хочешь универсальности
и удобств - оставайся на том, на чем работаешь, но смирись с ограничениями.

А с какими ограничениями? По сравнению с Кэш например

с обычными для всех РСУБД. объем и скорость.

С уважением. Сергей
6 май 06, 10:13    [2638185]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Sergei Obrastsov
tygra
автор
хочешь универсальности
и удобств - оставайся на том, на чем работаешь, но смирись с ограничениями.

А с какими ограничениями? По сравнению с Кэш например

с обычными для всех РСУБД. объем и скорость.

С уважением. Сергей

Вау, как доказательно то! И не опровергнуть
Хотя многие пытались доказать это, но не смогли - плохо знали РСУБД

-- Tygra's --
6 май 06, 10:25    [2638249]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

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

ты вот зря его не слушаешь, он дело говорит.


2. По словам и фразам нужно будет определить тематику более вероятную.
3. Составить план перевода каждого предложения. (Тут очень много сложностей)
4. Выбрать наиболее подходящие слова по оценочной функции и сделать перевод.

ты все-таки собираешься делать переводы по словам?
"Я ты давать курить"?

Ты просто убъешь лишней информацией базу.

С уважением. Сергей
6 май 06, 10:28    [2638278]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
По поводу самой технологии системы перевода - действительно, чудовищно все задумано. Так, как представлено, работать не будет, даже сейчас видно.
Невозможно правильно перевести по словам - но в смысле предложения.
Особенно невозможно перевести предложение и разбить его на слова с переводом - потому что перевод не обязательно совпадет по количеству слов и уж тем более редко совпадет по распложению.
Ну и много всего такого

Утопическая задача.

-- Tygra's --
6 май 06, 10:32    [2638296]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
tygra
Sergei Obrastsov
tygra
автор
хочешь универсальности
и удобств - оставайся на том, на чем работаешь, но смирись с ограничениями.

А с какими ограничениями? По сравнению с Кэш например

с обычными для всех РСУБД. объем и скорость.

С уважением. Сергей

Вау, как доказательно то! И не опровергнуть
Хотя многие пытались доказать это, но не смогли - плохо знали РСУБД

-- Tygra's --

без эмоций не получается? :) значит доказать не смогли? ладно, я тут
недавно давал расклад, во что превращается 18 млн. записей с одним
индексом в SQL и Cache. теперь твоя очередь доказывать мне, что я
не прав.

С уважением. Сергей
6 май 06, 10:32    [2638301]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
Sergei Obrastsov
Iura
Вот это все будет учитывать программа. Только она не будет вдаватся в смысл предложений, а будет использовать статистику. Она будет хранить все варианты переводов, которые когда либо будут вносится Пользователями.

ты вот зря его не слушаешь, он дело говорит.


2. По словам и фразам нужно будет определить тематику более вероятную.
3. Составить план перевода каждого предложения. (Тут очень много сложностей)
4. Выбрать наиболее подходящие слова по оценочной функции и сделать перевод.

ты все-таки собираешься делать переводы по словам?
"Я ты давать курить"?

Ты просто убъешь лишней информацией базу.

С уважением. Сергей


Сергей - я не исключаю, что в базе будет 90% ерунды.
Поэтому я полагю разделить базу данных на две части
То что, всречается очень часто и то что встречается очень редко.
Если статистика использования слова или словосочетание или предложения или пару предложений из базы данных "редко встречаются" растет и увеличивается, то эта комбинация мигрирует в базу данных "часто встречается".

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

Сергей, а как на счет последнего вопроса по Web страничкам?
Возможно это сделать на Cache ?
6 май 06, 10:38    [2638332]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
mir
Безграмотная писанина. Фраза «двумерными реляционными моделями данных» говорит о многом. Во-первых, писавший уверен, что реляционных моделей данных много. Во-вторых, он думает, что к понятию «модель данных» приложимо понятие «измерение/размерность». И при этом РМД почему-то именно двумерная. Автор непостижимым образом уверен, что количество таблиц каким-то образом влияет на транзакции. Что «большое количество таблиц» ведет к «хранению излишней информации».

видимо не ведет? или это считается "неизбежным"?


Фраза про «двумерные»/«плоские» реляционные таблицы вообще традиционный показатель слабого понимания. Да, физически нарисованная на бумаге таблица — плоская, потому, что плоский лист бумаги. Но логическая R-таблица, а точнее отношение вообще не имеет измерений, ни двух, ни одного, ни двухсот. И, кстати, если уж приспичит говорить про многомерность, то кортежи отношения с N атрибутами представляют точки N-мерного пространства. Говорить же, что «информация многомерна» — в общем случае бессмыслица. Короче, несмотря на утверждение про «простую для понимания математическую модель», для авторов она оказалась слишком сложной, не осилили.

что ж, действительно "ниасилил".

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

серьезно? а что там есть? там есть только X и Y? мы говорим о практической
реализации, если это не видно с первого раза


Для начала пояснить, что вы понимаете под деревом? Если это то, что понимается в математике (теории графов), то опишите строгое соответствие между понятиями из РМД (домен, атрибут, кортеж, отношение) и из теории графов (вершина, ребро). Сразу станет ясна ваша мысль.
Укажу лишь, что в таком аспекте любое дерево и вообще любой граф представляется одним отношением (таблицей смежности).

давай я не буду этого делать. теорию я оставляю тебе. я - практик, и
говорю о таких же вещах. если тебе что-то не нравится - можешь
сказать, я приму к сведению, ага
(только умствований мне для полного счастья не хватало)
6 май 06, 11:00    [2638457]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Iura
Сергей - я не исключаю, что в базе будет 90% ерунды.
Поэтому я полагю разделить базу данных на две части

и это тебя спасет? 32 Tb пополам - это 2 раза по 16 Tb. :)


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

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


Сергей, а как на счет последнего вопроса по Web страничкам?
Возможно это сделать на Cache ?

это не ко мне, я не занимаюсь Web-интерфейсами. но если
это вообще можно сделать, то в Cache это тоже получится.

С уважением. Сергей
6 май 06, 11:11    [2638518]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Sergei Obrastsov
без эмоций не получается? :) значит доказать не смогли? ладно, я тут
недавно давал расклад, во что превращается 18 млн. записей с одним
индексом в SQL и Cache. теперь твоя очередь доказывать мне, что я
не прав.

С уважением. Сергей

Это не эмоции, это факты.
Я почитал про 18 млн. записей - вывода только не нашел.
У нас вот полтора миллиона записей занимают почти 2 гига, и еще почти гиг индексы - это плохо или хорошо? По вашему наверное плохо - сильно много. А по мне хорошо - скорость выборок данных не напрягает.
Но одна фраза была интересна:
автор
Теперь дело за SQL. В наличии оказался только My SQL (ну, что есть).

Т.е. если например я начну сравнивать MS SQL с Кэшом, то это будет так:
т.к. у меня Кэша нет, я возьму Excel вместо него (ну что уж есть)
Ооооо!!!! Кошмар!!! Эксел больше 64000 строк не дает залить!!! Ну, все понятно с вашим Кэшом, г.... он, больше 64000 строк не может осилить.


Но даже и это не важно.
Результат, который должен быть - это не количество индексов, строк, деревьев, объем и т.д. Результат - это скорость получения данных оттуда, где они хранятся.
Такого сравнения нет. И обычно не бывает - ООБД-исты сразу забывают русский язык и все остальное, добиться от них алгоритма и теста на скорость разных выборок невозможно. Уже несколько раз пробовали - не получилось, молчат, как партизаны, только бубнят: а у нас лучше в n раз, но не покажем как это выглядит.

Кстати, предыдущий ваш пост подтвердил - как в чего конкретного просят, сразу: я практик, ничего рассказывать не буду, я и так все знаю, но не скажу

======

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

Sergei Obrastsov
P.S. Можно еще поразмыслить над структурой, но для этого надо
увидеть весь спектр желаемых тобой запросов. :)

Т.е. я правильно понимаю, что под каждый вариант запросов нужно делать еще одну структуру куда дублировать все данные, что есть?
Это называется круто?
Вы с обычными РСУБД когда-нибудь работали по-настоящему?

-- Tygra's --
6 май 06, 11:20    [2638557]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
tygra
Sergei Obrastsov
без эмоций не получается? :) значит доказать не смогли? ладно, я тут
недавно давал расклад, во что превращается 18 млн. записей с одним
индексом в SQL и Cache. теперь твоя очередь доказывать мне, что я
не прав.

С уважением. Сергей

Это не эмоции, это факты.
Я почитал про 18 млн. записей - вывода только не нашел.
У нас вот полтора миллиона записей занимают почти 2 гига, и еще почти гиг индексы - это плохо или хорошо? По вашему наверное плохо - сильно много. А по мне хорошо - скорость выборок данных не напрягает.
Но одна фраза была интересна:
автор
Теперь дело за SQL. В наличии оказался только My SQL (ну, что есть).

Т.е. если например я начну сравнивать MS SQL с Кэшом, то это будет так:
т.к. у меня Кэша нет, я возьму Excel вместо него (ну что уж есть)
Ооооо!!!! Кошмар!!! Эксел больше 64000 строк не дает залить!!! Ну, все понятно с вашим Кэшом, г.... он, больше 64000 строк не может осилить.


Но даже и это не важно.
Результат, который должен быть - это не количество индексов, строк, деревьев, объем и т.д. Результат - это скорость получения данных оттуда, где они хранятся.
Такого сравнения нет. И обычно не бывает - ООБД-исты сразу забывают русский язык и все остальное, добиться от них алгоритма и теста на скорость разных выборок невозможно. Уже несколько раз пробовали - не получилось, молчат, как партизаны, только бубнят: а у нас лучше в n раз, но не покажем как это выглядит.

Кстати, предыдущий ваш пост подтвердил - как в чего конкретного просят, сразу: я практик, ничего рассказывать не буду, я и так все знаю, но не скажу

======

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

Sergei Obrastsov
P.S. Можно еще поразмыслить над структурой, но для этого надо
увидеть весь спектр желаемых тобой запросов. :)

Т.е. я правильно понимаю, что под каждый вариант запросов нужно делать еще одну структуру куда дублировать все данные, что есть?
Это называется круто?
Вы с обычными РСУБД когда-нибудь работали по-настоящему?

-- Tygra's --


Тигра - форму- это не подиум, где восхваляют свои знания.

Давай сам сделай реальный маленький проект на Cache и SQL и сравни результаты. А то ты слишком перегибаешь в критике. Может быть ты и прав, но манера говорить добавляет в бочку меда ведро дегтя.
6 май 06, 11:27    [2638588]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
Sergei Obrastsov
без эмоций не получается? :) значит доказать не смогли? ладно, я тут
недавно давал расклад, во что превращается 18 млн. записей с одним
индексом в SQL и Cache. теперь твоя очередь доказывать мне, что я
не прав.

С уважением. Сергей
Вроде Вы показали размер БД в MS SQL server'e, а это ДАЛЕКО не все представители рода SQL-ного.

Причем во-первых, её также можно сжать (сделать денормализацию) и свести к одному столбцу.
Во-вторых MS SQL server ОЧЕНЬ не оптимально хранит данные. По месту стоит сравнивать с Sybase ASA. вроде примерно в 2-3 раза меньше места занимают, чем в MS SQL-e.

И вообще главное это отношение место (объем требуемых носителей и их цена) / скорость (как быстро мы можем получить/ изменить данные)
6 май 06, 11:33    [2638620]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
ошибся не MS SQL, а MySQL.

принцип не меняется
6 май 06, 11:39    [2638662]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
автор
я, видимо, плохо объясняю. :(
как работает SQL в этом случае? видимо, выбирая первичным индексом
для выборки то поле, которое позволит сузить количество обращений к базе.
ну а почему я должен действовать по-другому?

в этом случае структура превращается в вариант:

^x("d",n)=данные
^x("i1",i1,i2,i3)=n
^x("i2",i2,i1,i3)=n
^x("i3",i3,i1,i2)=n

что позволяет делать то, что хочешь ты, но неоптимально по размеру
ok, предложим другой:

^x("d",n)=данные
^x("i1",i1,n)=
^x("i2",i2,n)=
^x("i3",i3,n)=

в результате выборка сводится к варианту:
при известном i3 выбрать все n относящиеся к нему
если понадобится добавить условия на i1 и i2, тогда к предыдущему
действию добавляется проверка на наличие n по веткам "i1",i1 и
"i2",i2

С уважением. Сергей

P.S. Можно еще поразмыслить над структурой, но для этого надо
увидеть весь спектр желаемых тобой запросов. :)



Помнишь на странице 4-6 я тебя спрашивал что данные или запросы пользоватлей могут изменится и тебе придется переписывать код добавлять новые структуры.

Ты сам это подтверждаешь.

В случае с реляционной БД, нужно будет построить еще один индекс который позволит иметь мне необходимую производительность на новом классе запросов.
И не надо. Глупо переписывать код когда можно поменять административно в одном месте. Да это будет затратно с точки зрения места на диске. Но любую ситуацию можно рассматривать применяя к ней фразу
Nothing free, nothing new, no magic.
И реляционный подход позволят достичь приемлемый результат бестрее в разы.
Ты с каше возможно сделашь, что это будет быстрее работать быстрее. Только тебе времении в разы больше потребуются.
6 май 06, 11:44    [2638683]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Уж до кучи: на ASA так же встроенный веб-сервер, который к примеру вешается на 80-ый порт и спокойно позволяет организовать работу с HTML (сайты) и XML (SOAP). Логика управления работой веб-сервера находится прямо в базе на языке хранимых процедур ASA, так что спокойно можно делать свои сайты и веб-сервисы, а так же работать с чужими веб-сервисами. Причем поддерживается все - от управления HTTP-заголовков, работой с HTTP-переменными, передачей данных через POST/GET/RCP/DOC до встроенных авторизации и поддержкой сертификатов для создания защищенных каналов. Это при том, что сам Engine ASA весит 10 мб и стоит по процессорным лицензиям копейки по сравнению с другими СУБД. Так что если и хочется сравниваться с РСУБД, welcome to ASA, особенно с новой 10-ой версией - тут мы готовы и веб и версионность и мат представления и кластеры и скорость - все что угодно сравниваться, для сервера это только на пользу :)
6 май 06, 11:48    [2638701]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
tygra
Это не эмоции, это факты.

okey-dokey, оценим факты.


Я почитал про 18 млн. записей - вывода только не нашел.

вывод там был, просто я не рисовал его гигантскими буквами и в цвете.
зачем?
18 млн.записей c одним индексом в My SQL уходят за 4Gb, в Cache - 1.15Gb


У нас вот полтора миллиона записей занимают почти 2 гига, и еще почти гиг индексы - это плохо или хорошо? По вашему наверное плохо - сильно много. А по мне хорошо - скорость выборок данных не напрягает.

не знаю, может и нормально.
но если 4Gb и 1.15Gb - фигня, то 40 и 11 - уже заметно, а 400Gb и 115Gb - просто две большие разницы, не находишь?
а в моем случае, при малом объеме винта - страшно существенно.


Т.е. если например я начну сравнивать MS SQL с Кэшом, то это будет так:
т.к. у меня Кэша нет, я возьму Excel вместо него (ну что уж есть)
Ооооо!!!! Кошмар!!! Эксел больше 64000 строк не дает залить!!! Ну, все понятно с вашим Кэшом, г.... он, больше 64000 строк не может осилить.


знаешь, даже не смешно, а просто глупо. тогда уж возьми Access, он хоть
где-то на БД похож. My SQL - это тоже SQL, хоть и простенький. нижний
уровень у них примерно одинаковый. если хочешь меня опровергнуть -
растиражируй данную мной строку 18 млн. раз и засунь в таблицу.
получишь 2-3 гига вместе с индексом, я извинюсь перед всеми за дезу
и попрошу научить меня так делать.


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

речь ИЗНАЧАЛЬНО шла об объеме хранимой информации. поэтому не надо
меня обвинять в том, чего я не делал.


И обычно не бывает - ООБД-исты сразу забывают русский язык и все остальное, добиться от них алгоритма и теста на скорость разных выборок невозможно. Уже несколько раз пробовали - не получилось, молчат, как партизаны, только бубнят: а у нас лучше в n раз, но не покажем как это выглядит.

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


Кстати, предыдущий ваш пост подтвердил - как в чего конкретного просят, сразу: я практик, ничего рассказывать не буду, я и так все знаю, но не скажу

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


Т.е. я правильно понимаю, что под каждый вариант запросов нужно делать еще одну структуру куда дублировать все данные, что есть?
Это называется круто?

это называется "построение оптимальной структуры"
поэтому я и хочу увидеть весь "спектр". откуда взялась эта глупость
про "дублирование данных", сам придумал?!


Вы с обычными РСУБД когда-нибудь работали по-настоящему?

да, много. работаю и сейчас

С уважением. Сергей
6 май 06, 12:00    [2638771]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Andreww
Member [заблокирован]

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

>>Вы с обычными РСУБД когда-нибудь работали по-настоящему?

>да, много. работаю и сейчас

И как там "номера" ?

На ёлку похожи ?

))))))))))))))))))))))))

Работайте на здоровье, с такими "конкурентами" в лице КЭША и прочих МУМУ никаких препядствий для РСУБД пока не видно.
6 май 06, 12:05    [2638795]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Nikolay Kulikov
Помнишь на странице 4-6 я тебя спрашивал что данные или запросы пользоватлей могут изменится и тебе придется переписывать код добавлять новые структуры.
Ты сам это подтверждаешь.
В случае с реляционной БД, нужно будет построить еще один индекс который позволит иметь мне необходимую производительность на новом классе запросов.
И не надо. Глупо переписывать код когда можно поменять административно в одном месте. Да это будет затратно с точки зрения места на диске. Но любую ситуацию можно рассматривать применяя к ней фразу
Nothing free, nothing new, no magic.
И реляционный подход позволят достичь приемлемый результат бестрее в разы.
Ты с каше возможно сделашь, что это будет быстрее работать быстрее. Только тебе времении в разы больше потребуются.

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

ну что вы как дети, ей богу? :))

С уважением. Сергей
6 май 06, 12:06    [2638804]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
>>Т.е. я правильно понимаю, что под каждый вариант запросов нужно делать еще одну структуру куда дублировать все данные, что есть?

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

Ответы то ведь Вам простые и ясные дают.
Вот давайте проверим, что будет непонятно в следующем ответе?

Под каждый вариант запросов совершенно необязательно делать еще одну структуру, куда потребуется дублировать все данные. Однако, в самом деле, новый запрос предполагает написание новой процедуры выборки ( как, впрочем, и новый запрос в SQL так же предполагает его написание).

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

А что, при проектировании реляционных баз всё иначе?
6 май 06, 12:07    [2638811]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
ASCRUS
Уж до кучи: на ASA так же встроенный веб-сервер, который к примеру вешается на 80-ый порт и спокойно позволяет организовать работу с HTML (сайты) и XML (SOAP).


А вот из вашего лагеря вам же ответ :)

tygra
Однако иметь сервер БД в открытом доступе для всего инета - это умно, ничего не скажешь :))

-- Tygra's --



Если это про Каше - значит плохо
Если это же самое про ASA - значит хорошо
Ситуация понятна.. - "ворон ворону глаз не выклюет"
6 май 06, 12:15    [2638855]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
yww@escape.ru
ASCRUS
Уж до кучи: на ASA так же встроенный веб-сервер, который к примеру вешается на 80-ый порт и спокойно позволяет организовать работу с HTML (сайты) и XML (SOAP).


А вот из вашего лагеря вам же ответ :)

tygra
Однако иметь сервер БД в открытом доступе для всего инета - это умно, ничего не скажешь :))

-- Tygra's --



Если это про Каше - значит плохо
Если это же самое про ASA - значит хорошо
Ситуация понятна.. - "ворон ворону глаз не выклюет"

Это где это там наш лагерь ? Я с MSSQL не работаю уже давно, но могу твердо подтвердить слова Тигры - иметь в открытом доступе БД на MSSQL для всего интернета - это умно, ничего не скажешь. Однако ... для всех остальных эти слова будут интерпретироваться в зависимости от того, для чего сервер открыт в интернете и какой это сервер.
6 май 06, 12:20    [2638876]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 19   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить