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

Откуда: МО Электросталь
Сообщений: 5994
У меня складывается впечатление, что все недопонимания из за разного трактования смысловой нагрузки слова "Программист". Если рассматривать программист в контексте кодера, то наверное все присутствующие проектировщики БД на РСУБД не являются программистами и уж тем более матерыми - лет 10-15 назад может быть и было интересно код ручками писать, сейчас же необходимость писать какой либо код, не являющейся бизнес-логикой (куда уж впервую очередь входит понятие циклов), для меня только означает, что проект (не обязательно БД, все части) криво спроектирован.

Так что IMHO MUMPS, CACHE, всякие ООСУБД - это не для нас, нет никакого желания кодировать и быть матерыми программистами, есть желание побольше работать головой и поменьше руками. Сам по себе с моей точки зрения SQL по синтаксису кривоват, однако удивляет постоянное аппелирование противников РСУБД к самому языку запросов SQL, когда это всего лишь верхнеуровневой скриптовый язык обращения к мощным механизмам хранения и обработки данных РСУБД. Для меня это чисто кодерская позиция - сравнивать продукты с точки зрения синтаксиса (аля Pascal vs C) вместо того, чтобы сравнивать парадигмы разработки приложений.
5 май 06, 12:39    [2634131]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

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

1 Раз циклы написал проггер, разрабатывающий логику приложения, а не само СУБД, то этот факт не уберешь.

почему бы это? или СУБД у нас пишут уже не программисты? :)


2 Циклы по БД в программе - нужно уточнять хде они были раньше (они вседа в той или иной программе).

а какая разница "хде"?

vadiminfo

Sergei Obrastsov

шаг № 2:
теперь запрос выглядит так:

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

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

Sergei Obrastsov

шаг № 3:
я гордо заявляю: у меня в БД циклов нет!

vadiminfo

А они у Вас были в БД? Обыкновенно в БД данные. Ну ХП там хранятся. Ну даже сами проги, но тока хранятся. Нужно теперь уточнять чем Вы гордитесь теперь.

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

С уважением. Сергей
5 май 06, 12:41    [2634141]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
MX -- ALEX
Guest
SergSuper
MX -- ALEX

у нас в М есть встроенный генератор отчетов и поисковик
90 % задач решается путем составления запросов
без циклов

нестандартные задачи - например увязка с АСУТП
потребовали спец програмирования с циклами опроса датчиков

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

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


задачку Эйнштейна проще решить пятью строчками м-кода
с циклами чем составлять сложный запрос
он сложный как в SQL так и у нас в м-генераторе отчетов

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

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

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

Если честно, меня Кеша сильно оталкивает тем, что онам менее распространеная.
Если предположить, что MySQL в 10 раз хуже чем MSSQL и ORACLE, то не смотря на это про это продукт многие занют. им многие пользуются По нему есть куча документация на разных языках + книги. Что имеет большое значение.

А по Cache есть единственная книжка на русском. Маркетинг очень хреновый у Cache, если продукт и правдо хорош.

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

tb_slovar
(
id_slovo bigint
slovo nvarchar(64)
)


tb_text(
id_text bigint,
text nvarchar(max)
)

tb_predlojenie(
id_predlojenie int,
id_text bigint,
positsia int)


tb_slova(
id_slovo bigint,
id_predlojenie int,
id_text bigint,
positsia smalint)


У меня душа не лежит для каждого слова предложения из текста хранить информацию id_predlojenie int + id_text bigint = 12 bait + 8 bait id samogo slova - 20 bait инфы на слово из текста. А это очень и очень много. Как эту структуру можно представить оптимально на Кеше ?
5 май 06, 12:53    [2634236]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

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

Было уже, проходили и не раз. И даже на этом форуме.
Если всё так легко, то представте мне пожалуйста таблицу с тремы столбцами (остальные можно опустить как несущественные)

1. ТИП ДОКУМЕНТА
2. ДАТА ОПЕРАЦИИ
3. СУММА
ИМХО, типичный набор для любой учётной задачи.
Ессс-но нужно что бы поиск по ЛЮБОМУ из полей или ЛЮБОЙ ИХ КОМБИНАЦИИ был оптимальным и не сильно зависел от кардинальности.

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


>>первый уровень - индекс, второй - номер записи.
А что такое "НОМЕР ЗАПИСИ" ?

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


Нифига не понял почему уровня 2, и кому такое дерево нафиг нужно....

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


Если уровень в дереве только ОДИН это уже список а не дерево.

правильно. такой вот частный случай.

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

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

почему бы это? или СУБД у нас пишут уже не программисты? :)

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

Sergei Obrastsov

а какая разница "хде"?

Если никакой разницы, то зачем Вы их "убирали в программу"? Ить разницы же нет?

Sergei Obrastsov

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

Он декларативный - инфа из БД без циклов. А Вы про циклы. При этом он здесь.

Sergei Obrastsov

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

Отсутствовать циклы в запросах стали из-за того что Вы их "убрали в программу"? Сами говорите нет никакой разницы. Их написали Вы. Вот када проггер, пишущий СУБД уберет их в программу СУБД, тада другое дело. Тада запросы без циклов. А так просто структурное программирование. Разбил большую процедуру на мелкие и вызывает их. Вы сами выше писали, что это просто вызов Вашей же или Вашего коллеги проги. Это не запрос на декларативном языке БД. Две большие разницы. На Вашем языке писать циклы и их вызовы, а там запрос без циклов на основе содержания данных (ассоциативно).
5 май 06, 13:17    [2634408]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

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

не очень хороший аргумент. М-щики, в основной своей массе, как раз и
работали с РСУБД. а куда было деваться? я, например, с 91-го работаю
с Clarion. а дальше были и InterBase, и MSSQL, и DB2.
как-то раз пришлось восстанавливать убитый mdf-файл.
ага, с помощью M. такая вот дружба родов войск :)

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

Откуда: сеРверная пальмира :)
Сообщений: 4898
Sergei Obrastsov
верю. таблицы легко представляются в "деревьях", первый уровень - индекс, второй - номер записи. почему "дерево"? потому что похоже на елку, если
нарисовать (особенно отношение "1:any"). :)
почему только два уровня? потому что такие таблицы, там только
одно отношение. если индекс составной, то он скомбинирован.
так он выглядит логически, так он сделан и физически.
за исключением исходных данных, там только один уровень (номер записи)

С уважением. Сергей
Идем дальше.

Данные в М: родитель1 -> родитель2 -> лист дерева3
Даныне в РСУБД: таблица1, таблица2, таблица3.

номера сущьностей в М и РСУБД совпадают.

Запрос на получение 3 через известные 2 и 1 в М испольует доступ через 1->2->3, в Р 1->2->3.

Запрос на получение всех 1, у которых есть только требуемые 3 (пример: вывести счета по которым у компании покупали продукцию 3)
Р ищем (сканируем) 3, затем БЕЗ ЦИКЛОВ из связки 3->2->1 получаем 1.

А как в М?


ЗЫ 1,2,3 - это различные сущьности, связанные отношением см. выше.
5 май 06, 13:26    [2634479]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

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

не очень хороший аргумент. М-щики, в основной своей массе, как раз и
работали с РСУБД. а куда было деваться? я, например, с 91-го работаю
с Clarion. а дальше были и InterBase, и MSSQL, и DB2.
как-то раз пришлось восстанавливать убитый mdf-файл.
ага, с помощью M. такая вот дружба родов войск :)

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


Сергей как моя структура выглядела бы в Cache если бы потребовалось оптимизировать ее? Все также ?

Сижу тихо тихо качаю Cache думаю начать и Oracle качать, а пока использую MS SQL. С базой пока не определился :(
5 май 06, 13:27    [2634492]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Andreww
Member [заблокирован]

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

Ну во-первых я вам не ТЫ-кал.

Про "деревья похожие на ёлки" :

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

Т.е. дерево с одним уровнем , т.е. СПИСОК :)

Забавно, вы не находите ?

Получается так :

>>>таблицы легко представляются в "деревьях"

>> А представьте-ка мне простую (синтетический тестик) табличку

> Ээээ а как ? Может вот такой случай - и рисуется простой связный список.

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

Что будет когда данные будут сложными, декомпозированными на десяток-другой таблиц, нормализованными - лучше даже и не рассматривать, хотя иногда (в1-2%) случаев данные может быть действительно оптимально хранить данные в виде деревьев.

>>а он самый и есть. впрочем, да, его же не видно.

А что такое НОМЕР ?

А ОН САМЫЙ И ЕСТЬ.

Это сильно ! Мощь ответа и глубина поражают :) Воистину с МУ-МУ технологиями работают не просто знатные специалисты, а настоящий мастера ДЗЕН !

>>хотя если просматривать любую таблицу средствами самой СУБД, то он
рисуется в первом столбике (это, конечно, не совсем он, но
в принципе - да) :)

Oracle 9.2 (Субд такая) + sqlplus(w) (родное его средство)
делаем select * from user_tables; Хмммм. Первым столбцом идёт Table_name :)

>>верю. потому что таблица плоская.

Стараюсь при работе с РСУБД не оперировать понятиями типа "таблица" и вам не советую, так проще, поскольку в реляционной модели таблиц нету.

>>не знаю, оно просто есть. можешь на него не смотреть. :)

Да я вобщем-то и не собирался :) Просто спросил, для расширения кругозора, для чего существует такая структура, оказывается ПРОСТО ЕСТЬ.
Хммм. Ёмкий ответ.


>>а если серьезно, то это просто визуальное представление

Так что же вы сразу не сказали !!! Я тут о базах данных о структурах об оптимальности, а это просто ВИЗУАЛЬНОЕ ПРЕДСТАВЛЕНИЕ :)
Т.е. берёте пару опытных кодировщиков и они вам ИЗ ЛЮБЫХ ДАННЫХ могут наваять ТАКОЕ ВИЗУАЛЬНОЕ ПРЕДСТАВЛЕНИЕ, хошь с трёхмерной графикой хошь со звуком и не надо НИКАКИХ МУМУ и ОРАКЕЛОВ и дешевле кстати выйдет.

>>правильно. такой вот частный случай.

Есс-но правильно, т.к. это был не ответ а утверждение :)
5 май 06, 13:35    [2634544]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Iura
Сергей как моя структура выглядела бы в Cache если бы потребовалось оптимизировать ее? Все также ?

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


С базой пока не определился :(

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

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

P.S. И все же я не уверен, что тебе нужен Cache.
5 май 06, 13:39    [2634583]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

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

Ну во-первых я вам не ТЫ-кал.

что ж, перейдем на Вы


Т.е. дерево с одним уровнем , т.е. СПИСОК :)
Забавно, вы не находите ?

нет. а "плоская таблица" выглядит по-другому?


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

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


Что будет когда данные будут сложными, декомпозированными на десяток-другой таблиц, нормализованными - лучше даже и не рассматривать, хотя иногда (в1-2%) случаев данные может быть действительно оптимально хранить данные в виде деревьев.

"товарищ не понимает". :)
этот "десяток-другой таблиц" не будет выглядеть как
"индекс->ссылка на запись в другой таблице"? ах ну да, это же не дерево,
это - ТАБЛИЦА, да? ну, все понятно


А что такое НОМЕР ?
А ОН САМЫЙ И ЕСТЬ.
Это сильно ! Мощь ответа и глубина поражают :) Воистину с МУ-МУ технологиями работают не просто знатные специалисты, а настоящий мастера ДЗЕН !

каков вопрос - таков и ответ.
индексные таблицы ссылаются на номер записи


Oracle 9.2 (Субд такая) + sqlplus(w) (родное его средство)
делаем select * from user_tables; Хмммм. Первым столбцом идёт Table_name :)

может проще сделать по одной таблице?


>>верю. потому что таблица плоская.
Стараюсь при работе с РСУБД не оперировать понятиями типа "таблица" и вам не советую, так проще, поскольку в реляционной модели таблиц нету.

"select * from user_tables" - видимо, tables теперь переводят по-другому


>>правильно. такой вот частный случай.
Есс-но правильно, т.к. это был не ответ а утверждение :)

наверное должно было быть "не вопрос". впрочем, неважно

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

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
VoDA
Идем дальше.

Данные в М: родитель1 -> родитель2 -> лист дерева3
Даныне в РСУБД: таблица1, таблица2, таблица3.

номера сущьностей в М и РСУБД совпадают.

Запрос на получение 3 через известные 2 и 1 в М испольует доступ через 1->2->3, в Р 1->2->3.

Запрос на получение всех 1, у которых есть только требуемые 3 (пример: вывести счета по которым у компании покупали продукцию 3)
Р ищем (сканируем) 3, затем БЕЗ ЦИКЛОВ из связки 3->2->1 получаем 1.

А как в М?


ЗЫ 1,2,3 - это различные сущьности, связанные отношением см. выше.

Я малость выше об этом же спрашивал - нет ответа, не слышуть, когда конкретика начинается :)
А хотелось бы все же узнать - в цикле по всем 1 будете идти и проверять, есть ли там 3???

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

Откуда: Москва
Сообщений: 1276
Iura
Есть четыре таблицы: Текст, предложения, слова, словарь
вот их описания. Таблицы не имеют отношение к самой реализации проекта, но я передам суть вопроса на их примере еще раз

tb_slovar
(
id_slovo bigint
slovo nvarchar(64)
)

tb_text(
id_text bigint,
text nvarchar(max)
)


Это оригинальные содержательные данные, видимо. Как вариант мог бы быть такой:
^tbslovar(idslovo)=slovo
Ну и наверно обратный индекс чтобы найти ид слова
^itbslovar(slovo,idslovo)=""

^tbtext(idtext)=text
Тут лимит 32 кила на длину строки, если нужно больше то надо раскладывать по частям или использовать классы потоков (что технически то же самое).

Iura
tb_predlojenie(
id_predlojenie int,
id_text bigint,
positsia int)


tb_slova(
id_slovo bigint,
id_predlojenie int,
id_text bigint,
positsia smalint)

А это уже видимо для поиска. Если нужно брать позицию предложения в тексте, то могло бы быть так
^itbpredlojenie(idpredlojenie,idtext,positsia)=""
Если нужно брать позицию слова в тексте и в предложении, то наверно так
^itbslova(idslovo,idtext,idpredlojenie,positsia)=""

Например, если задано слово то по ^itbslovar(slovo) берем idslovo, и по ^itbslova(idslovo,idtext,idpredlojenie,positsia)=""
получаем сначала тексты, в которых оно есть, по текстам - предложения, по предложению - позицию.

Имея только таблицы, тут можно оперировать разве что как sql-щики, больше пока ничего не задано. Если есть уточнения насчет операций со словами - предложениями, то можно уточнить и схему. А пока вы от sql недалеко ушли.
5 май 06, 14:04    [2634796]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
ну я
Iura
Есть четыре таблицы: Текст, предложения, слова, словарь
вот их описания. Таблицы не имеют отношение к самой реализации проекта, но я передам суть вопроса на их примере еще раз

tb_slovar
(
id_slovo bigint
slovo nvarchar(64)
)

tb_text(
id_text bigint,
text nvarchar(max)
)


Это оригинальные содержательные данные, видимо. Как вариант мог бы быть такой:
^tbslovar(idslovo)=slovo
Ну и наверно обратный индекс чтобы найти ид слова
^itbslovar(slovo,idslovo)=""

^tbtext(idtext)=text
Тут лимит 32 кила на длину строки, если нужно больше то надо раскладывать по частям или использовать классы потоков (что технически то же самое).

Iura
tb_predlojenie(
id_predlojenie int,
id_text bigint,
positsia int)


tb_slova(
id_slovo bigint,
id_predlojenie int,
id_text bigint,
positsia smalint)

А это уже видимо для поиска. Если нужно брать позицию предложения в тексте, то могло бы быть так
^itbpredlojenie(idpredlojenie,idtext,positsia)=""
Если нужно брать позицию слова в тексте и в предложении, то наверно так
^itbslova(idslovo,idtext,idpredlojenie,positsia)=""

Например, если задано слово то по ^itbslovar(slovo) берем idslovo, и по ^itbslova(idslovo,idtext,idpredlojenie,positsia)=""
получаем сначала тексты, в которых оно есть, по текстам - предложения, по предложению - позицию.

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



Поиск фразы будет вестись по таблице slova.
При переводе берется исходная фраза и ищется в таблице переведеных фраз (predlojenia). Пусть пока поиск ведется только по исходному тексту, без перевода. Искать по словам в таблице slova будет быстрее, чем сканировать весь тексты.

Можно получить все предложения, которые содержат слова
select pid_predlojenia
from slova
where id_slova in ( id_искомых слов)


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

Так вот этот алгоритм легко реализовать SQL, но тот факт что на слово в предложении приходится 20 байт - очень огорчает. Вроде бу немного. Но если подсчитать, сколько слов в тексте, а сколько будет текстов то получается очень и очень много. :(
5 май 06, 14:14    [2634869]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Iura, уже написали что структуры в кеше нет. Полная свобода. Делайте деревья, по которым надо будет искать. Сколько надо видов поиска - столько и деревьев. Т.е. данные будут дублироваться в разных деревьях и их синхронность надо поддерживать самостоятельно. Для настоящего программиста есть где развернуться. И еще учтите что Int-ов там нету, всё хранится строчками, что тоже несколько длиннее.
5 май 06, 14:17    [2634891]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
SergSuper
Iura, уже написали что структуры в кеше нет. Полная свобода. Делайте деревья, по которым надо будет искать. Сколько надо видов поиска - столько и деревьев. Т.е. данные будут дублироваться в разных деревьях и их синхронность надо поддерживать самостоятельно. Для настоящего программиста есть где развернуться. И еще учтите что Int-ов там нету, всё хранится строчками, что тоже несколько длиннее.


Хм. Мда. Строчками хранится ?
Как с целочисленой матетматикой в Cache ? С каким максимальным числом он работает ?
5 май 06, 14:20    [2634913]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
VoDA
Идем дальше.
Данные в М: родитель1 -> родитель2 -> лист дерева3
Даныне в РСУБД: таблица1, таблица2, таблица3.
номера сущьностей в М и РСУБД совпадают.
Запрос на получение 3 через известные 2 и 1 в М испольует доступ через 1->2->3, в Р 1->2->3.
Запрос на получение всех 1, у которых есть только требуемые 3 (пример: вывести счета по которым у компании покупали продукцию 3)
Р ищем (сканируем) 3, затем БЕЗ ЦИКЛОВ из связки 3->2->1 получаем 1.
А как в М?
ЗЫ 1,2,3 - это различные сущьности, связанные отношением см. выше.

небольшое уточнение: ты говоришь о том как это получается у тебя, с учетом
всего инструментария РСУБД, а от меня требуешь, чтобы я тебе показал это
БЕЗ ЦИКЛОВ на уровня языка. честно ли это? :) как это реализовано на
уровне объектов и псевдо-SQL в Cache - не знаю, мне это как-то неинтересно.
а хардкорно - без циклов не обойтись, кто же мне выбирать-то будет? :)

ну а если вопрос по структурам и, надеюсь, без дураков, то такая
связка реализуется в виде:

^x(i1,i2,i3) - удобнее, правда? то есть под каждым уровнем есть только
связанные с ним уровни и "листья дерева" (можно конечно и так сказать).

а можно и реализовать точь в точь как у тебя, через "двойки":

^x1(i1,i2)
^x2(i2,i3)

можно, но непрактично.

С уважением. Сергей
5 май 06, 14:20    [2634921]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
MX -- ALEX
Guest
Iura
Давайте я Вам реальный пример приведу задачи, а вы просто скажите как это будет выглядеть в Cache. Бессмыслен спор людей, которые реально не работали на двух языках. Пока собственными ручками не сделаешь проект там и там не поймешь все прелесть каждого продукта.

Если честно, меня Кеша сильно оталкивает тем, что онам менее распространеная.
Если предположить, что MySQL в 10 раз хуже чем MSSQL и ORACLE, то не смотря на это про это продукт многие занют. им многие пользуются По нему есть куча документация на разных языках + книги. Что имеет большое значение.

А по Cache есть единственная книжка на русском. Маркетинг очень хреновый у Cache, если продукт и правдо хорош.

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

tb_slovar
(
id_slovo bigint
slovo nvarchar(64)
)


tb_text(
id_text bigint,
text nvarchar(max)
)

tb_predlojenie(
id_predlojenie int,
id_text bigint,
positsia int)


tb_slova(
id_slovo bigint,
id_predlojenie int,
id_text bigint,
positsia smalint)


У меня душа не лежит для каждого слова предложения из текста хранить информацию id_predlojenie int + id_text bigint = 12 bait + 8 bait id samogo slova - 20 bait инфы на слово из текста. А это очень и очень много. Как эту структуру можно представить оптимально на Кеше ?


tb_slovar
(
id_slovo bigint
slovo nvarchar(64)
)

например словарь - это будет одномерное дерево
^slova("книг")
^slova("книга")
^slova("книголюб")

заранее ничего декларировать не надо
другие структуры тоже не декларируются
поэтому нет точного эквивалента Вашего представления в чистом мумпс
(если не использовать специальный SQL-наворот cache)

идентификаторов не надо - само слово является идентификатором
как будет организован ввод данных - неважно
(это зависит от м-инструмента)
главное что после ввода - корректировки появится это дерево

экономия например за счет того что совпадающаая часть индекса
"^slova("кни"
хранится один раз
- излагаю упрощенно

хотя это не существенно и не сильно повлияет на скорость и обьем
5 май 06, 14:22    [2634930]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
SergSuper
И еще учтите что Int-ов там нету, всё хранится строчками, что тоже несколько длиннее.

Это в стандарте на М не регламентировано. А что касается именно каше, то если значение получено в результате числовой операции то оно остается числом и во внутреннем представлении. И пишется как число.

2 lura
Как с целочисленой матетматикой в Cache ? С каким максимальным числом он работает ?

Целые числа - 2 в степени 63 максимум если гарантированно.
5 май 06, 14:28    [2634992]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

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


Хм. Мда. Строчками хранится ?
Как с целочисленой матетматикой в Cache ? С каким максимальным числом он работает ?

"он над нами издевался..." да пусть порезвится. :)
строками. да нормально вроде, хватает. 1e18
5 май 06, 14:28    [2634996]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Hima
Member

Откуда:
Сообщений: 12
SergSuper
Iura, уже написали что структуры в кеше нет. Полная свобода. Делайте деревья, по которым надо будет искать. Сколько надо видов поиска - столько и деревьев. Т.е. данные будут дублироваться в разных деревьях и их синхронность надо поддерживать самостоятельно. Для настоящего программиста есть где развернуться. И еще учтите что Int-ов там нету, всё хранится строчками, что тоже несколько длиннее.


Ну а как же %Library.Integer? ... в итоге конечно же всеравно храниться строкой, но индексируется числа же все-таки лучше....
5 май 06, 14:29    [2635001]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Sergei Obrastsov
небольшое уточнение: ты говоришь о том как это получается у тебя, с учетом
всего инструментария РСУБД, а от меня требуешь, чтобы я тебе показал это
БЕЗ ЦИКЛОВ на уровня языка. честно ли это? :) как это реализовано на
уровне объектов и псевдо-SQL в Cache - не знаю, мне это как-то неинтересно.
а хардкорно - без циклов не обойтись, кто же мне выбирать-то будет? :)

ну а если вопрос по структурам и, надеюсь, без дураков, то такая
связка реализуется в виде:

^x(i1,i2,i3) - удобнее, правда? то есть под каждым уровнем есть только
связанные с ним уровни и "листья дерева" (можно конечно и так сказать).

а можно и реализовать точь в точь как у тебя, через "двойки":

^x1(i1,i2)
^x2(i2,i3)

можно, но непрактично.

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

А можно для меня решение, хоть с циклами, хоть без - вообще решение?
А то так и не понятно - есть ли оно, решение, или нет :)

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

Откуда:
Сообщений: 138
MX -- ALEX


tb_slovar
(
id_slovo bigint
slovo nvarchar(64)
)

например словарь - это будет одномерное дерево
^slova("книг")
^slova("книга")
^slova("книголюб")

заранее ничего декларировать не надо
другие структуры тоже не декларируются
поэтому нет точного эквивалента Вашего представления в чистом мумпс
(если не использовать специальный SQL-наворот cache)

идентификаторов не надо - само слово является идентификатором
как будет организован ввод данных - неважно
(это зависит от м-инструмента)
главное что после ввода - корректировки появится это дерево

экономия например за счет того что совпадающаая часть индекса
"^slova("кни"
хранится один раз
- излагаю упрощенно

хотя это не существенно и не сильно повлияет на скорость и обьем


Люди кто-то знаком с Прологом? Мне чем-то это дело напоминает концепцию Пролога.
5 май 06, 14:35    [2635049]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Iura
Поиск фразы будет вестись по таблице slova.
При переводе берется исходная фраза и ищется в таблице переведеных фраз (predlojenia).

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


Так вот этот алгоритм легко реализовать SQL, но тот факт что на слово в предложении приходится 20 байт - очень огорчает. Вроде бу немного. Но если подсчитать, сколько слов в тексте, а сколько будет текстов то получается очень и очень много. :(

тут можно подумать о некоей "математике" над словами. скажем приведение
к виду: fn(приставка) + fn(корень) + fn(суффикс) + fn(окончание). в результате можно приводить его к числу размером, скажем, в 4 байта. ну
и конечно справочники частей слова. и все же выигрыш будет достаточный

С уважением. Сергей
5 май 06, 14:48    [2635186]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 19   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить