Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Привет всем! Пожалуйста, люди, которые работали с SQL 2005, Oracle 10G, Cache 5, MySQL укажите 5 сильных и 5 слабых сторон каждого продукта. С уважением, Юрий ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2006, 15:28 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
товарищщ Юра, сначала объясни пожалуйста зачем этому человеку (интересно есть такие?) писать про 40 разных сторон? Я понимаю если помочь кому надо, но не удовлетворять же чьё-то празное любопытство ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2006, 00:48 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Мне нужно выбрать оптимальную с точки зрения разработки и быстродействия базу данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2006, 08:18 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
на чем умеете на том и пишите. Это самый оптимальный вариант обычно оказывается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2006, 08:46 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Iura . Если бы была одна оптимальная база, то все другие вымерли бы. Сильная сторона MS SQL - я его хорошо знаю! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2006, 11:23 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Мне нужен совет человека, который имел опыт написания баз данных на всех этих продуктах. Я уверен что их немного, но их мнение имеет большой вес. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2006, 11:53 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Iura. Нет таких наверное. Хотя бы из-за того, что SQL 2005 и Oracle 10G довольно свежие продукты и вряд-ли кто-то успел изучить все их тонкости одновременно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2006, 12:05 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
IuraМне нужно выбрать оптимальную с точки зрения разработки и быстродействия базу данных. А почему хотите выбирать только по этим критериям? Например, сколько заказчик готов заплатить за СУБД, хардварь и разработку БД? Или, для начинающего разработчика, должен быть важен такой вопрос: разработчики для каких СУБД более всего востребованы? а какие получают наивысшую зарплату? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2006, 13:06 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Так, я предполагаю (не знаю, на самом деле, просто предполагаю), что ораклисты получают больше, чем мс-скулисты, а те намного больше, чем май-скулисты. Cache' - жуткая экзотика, труднее будет сменить работу на другую с Cache', а знания приобретаются не за один день и не за один год. Это весьма важные соображения для программиста и админа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2006, 13:21 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa . Вы правы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2006, 15:11 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
И почему только я работаю по большей части с DB2? ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2006, 20:27 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Я не могу создать оптимальную структуру базы даннах на Oracle & SQL, но полагаю, что ее возможно сделать на Cache. То есть, мне нужно для каждого уникального ключа хранить несколько значений (список). Я не хочу вместе с каждым значением списка хранить его ключ. Это допустимо для небольших таблиц. Но если число записей более 1 000 000? Это просто не экономное использование памяти. Для кажой группы записей должно быть всего лишь одноразовое упоминание, к какому значению ID оно принадлежит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2006, 22:05 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Iura. Никто не запрещает Вам сделать таблицы без явно определенного индекса в MS SQL. Только вот выйдет вам это боком, когда вы соберетесь редактировать одну запись из "группы". Не путайте индексы и ключи! Ключ - это набор полей, который уникально определяет запись. Индекс - это структура, которая позволяет быстро найти запись по ключу. Бывают случаи, когда построение индекса невыгодно. Миллион записей - это семечки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2006, 23:02 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
IuraТо есть, мне нужно для каждого уникального ключа хранить несколько значений (список). Я не хочу вместе с каждым значением списка хранить его ключ. Это допустимо для небольших таблиц. Но если число записей более 1 000 000? Это просто не экономное использование памяти. Для кажой группы записей должно быть всего лишь одноразовое упоминание, к какому значению ID оно принадлежит. А за каждый сэкономленный мегабайт и ускорение на микросекунду дадут премию ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2006, 23:11 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Ой-ой! Надо быстро написать, пока пинать не начали! Это про индекс по первичному ключу. Можно ведь и другие индексы сделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2006, 23:19 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
IuraЯ не могу создать оптимальную структуру базы даннах на Oracle & SQL, но полагаю, что ее возможно сделать на Cache. То есть, мне нужно для каждого уникального ключа хранить несколько значений (список). Я не хочу вместе с каждым значением списка хранить его ключ. Это допустимо для небольших таблиц. Но если число записей более 1 000 000? Это просто не экономное использование памяти. Для кажой группы записей должно быть всего лишь одноразовое упоминание, к какому значению ID оно принадлежит. Насколько я читал, что сама база Кэш не оптимальна, те занимает места намного больше чем РСУБД при наличии того объема данных... Это если разговор идет именно о критичности расхода памяти (места на дисках)... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2006, 23:45 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Cat2Ой-ой! Надо быстро написать, пока пинать не начали! Это про индекс по первичному ключу. Можно ведь и другие индексы сделать. Как я понимаю, он про индексы и не писал, а речь шла о схеме вида master-slave (мощности 1:n), create table master( master_id primary key ... ) create table slave( slave_id primary key. master_id foreign key ... ) и он хотел сэкономить байты на master_id в таблице slave. Правда ли удастся сэкономить? На SQL это может выглядеть как 1) для каждого master_id (XXX) отдельная таблица slave_xxx или 2) таблица slave исчезает и возникает поле slaves типа BLOB или (в тех СУБД, где поддерживается) ARRAY в таблице MASTERS. Оба варианта выглядят не слишком хорошо. Ближе всего к пожеланию выглядело бы (на DB2) что-нибудь типа MDC (многомерный кластер) на таблице slave по master_id, но так, чтобы значение master_id в строке не хранилось, а только в специальном индексе, по которому организуется MDC. Это интересная мысль, надо перечитать текст про устройство MDC, есть ли там такая компрессия. Пока кажется, что всё же нет. Но это мне напомнило, что в Viper'е обещают гораздо более серьёзную компрессию . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.05.2006, 00:20 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa Cat2Ой-ой! Надо быстро написать, пока пинать не начали! Это про индекс по первичному ключу. Можно ведь и другие индексы сделать. Как я понимаю, он про индексы и не писал, а речь шла о схеме вида master-slave (мощности 1:n), create table master( master_id primary key ... ) create table slave( slave_id primary key. master_id foreign key ... ) и он хотел сэкономить байты на master_id в таблице slave. Правда ли удастся сэкономить? На SQL это может выглядеть как 1) для каждого master_id (XXX) отдельная таблица slave_xxx или 2) таблица slave исчезает и возникает поле slaves типа BLOB или (в тех СУБД, где поддерживается) ARRAY в таблице MASTERS. Оба варианта выглядят не слишком хорошо. Ближе всего к пожеланию выглядело бы (на DB2) что-нибудь типа MDC (многомерный кластер) на таблице slave по master_id, но так, чтобы значение master_id в строке не хранилось, а только в специальном индексе, по которому организуется MDC. Это интересная мысль, надо перечитать текст про устройство MDC, есть ли там такая компрессия. Пока кажется, что всё же нет. Но это мне напомнило, что в Viper'е обещают гораздо более серьёзную компрессию . Абсолютно правильно вы поняли идею. Из описания Cache я понял, что он позволяет эту проблему решить проще и красивее. Но я не могу использовать всего лишь этот единственный аргумент для выбора этой платформы в качестве среды разработки. Кажись есть похожая возможность у Oracle. Пока ничего незнаю на счет MySQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.05.2006, 10:15 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
luraТо есть, мне нужно для каждого уникального ключа хранить несколько значений (список). Я не хочу вместе с каждым значением списка хранить его ключ. Это допустимо для небольших таблиц. Но если число записей более 1 000 000? Это просто не экономное использование памяти. Для кажой группы записей должно быть всего лишь одноразовое упоминание, к какому значению ID оно принадлежит. У меня тока 2 вопроса 1. Вы давно ли начали этим делом баловаться? В смысле - проектированием БД :) 2. Кто вам сказал, что так, как вы почему-то не хотите, делать нельзя? Сон был в четверг? Или кто есть еще умнее вас? :)) Я боюсь подумать, но вы что, вправду считаете, что если вы явно не задаете ссылку на родительский объект для каждой записи, ее там и нет? А как тогда записи выбираются - чудо каждый раз БД творит? Давайте лучше постановку задачи опишите чтоли, сколько записей, сколько сущностей, чего делать и т.д. А то сразу - кэш, оракл, массивы.... :)) -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.05.2006, 14:18 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
tygraЯ боюсь подумать, но вы что, вправду считаете, что если вы явно не задаете ссылку на родительский объект для каждой записи, ее там и нет? А как тогда записи выбираются - чудо каждый раз БД творит? Не нужно чудес. Схема Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Хотя... экономия места всё равно весьма спорна. Если упаковывать массив плотно для всей таблицы, можно замучаться с управлением памятью, а если для каждого master_id выделять минимум экстент для его массива slaves, для выигрыша надо, чтобы эти массивы были весьма и весьма большие, а тогда, наверное, и записи в массивах будут достаточно широкие, и выигрыш на отсутствии "master_id foreign key" грошовый. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.05.2006, 15:00 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa Это легко вообразить для не-SQL-СУБД. Да и в Оракле представить моно легко (вложенные таблицы). Хуже представить как это потом запросы это прокорявит, када надо будет с этой инфой работать. Не та эта плата за экономию на диске. Логикой платить за физику что-то ломает без каких-то особых причин. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.05.2006, 16:01 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
vadiminfo Да и в Оракле представить моно легко (вложенные таблицы). Хуже представить как это потом запросы это прокорявит, када надо будет с этой инфой работать. А ты реально это пробывал делать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.05.2006, 16:34 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa Хотя... экономия места всё равно весьма спорна. Если упаковывать массив плотно для всей таблицы, можно замучаться с управлением памятью, а если для каждого master_id выделять минимум экстент для его массива slaves, для выигрыша надо, чтобы эти массивы были весьма и весьма большие, а тогда, наверное, и записи в массивах будут достаточно широкие, и выигрыш на отсутствии "master_id foreign key" грошовый. на специально подобранных задачах выигрыш может быть очень заметным. в доке на один из модулей такого сорта для Informix дается модельная оценка - два раза по размеру дискового пространства и 4 раза по операциям чтения (индекса) при поиске (~ время поиска). http://publib.boulder.ibm.com/epubs/pdf/6577a.pdf Overview->Case Studies Showing the Benefits... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.05.2006, 17:02 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Iuraи он хотел сэкономить байты на master_id в таблице slave. Кажись есть похожая возможность у Oracle. Если не ошибаюсь, у Oracle есть даже два варианта для этой возможности. Можно сделать INDEX CLUSTER, а можно - INDEX-ORGANIZED TABLE с ключом COMPRESS. Хотя лень лезть в доку проверять :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.05.2006, 21:30 |
|
||
|
Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )
|
|||
|---|---|---|---|
|
#18+
Iura Я не хочу вместе с каждым значением списка хранить его ключ. Это допустимо для небольших таблиц. Но если число записей более 1 000 000? Это просто не экономное использование памяти. Оптимизация - это в принципе хорошо. Оптимизация ради оптимизации- это плохо. Например: - Нам достаточно, чтобы запрос выполнялся за секунду- две. Он выполняется за полсекунды, на реальных данных. Незачем его оптимизировать, чтобы он выполнялся быстрее. - У нас диск в 40 ГБ, а БД занимает около 1 ГБ. Тогда нам незачем экономить на индексах, байтах или указателях. Что мы будем делать с оставшейся памятью? Унесем домой? В таких случаях как выше- имхо надо сосредоточиться не на экономии которая достигается за счет усложнения, а на понятных, стандартных решениях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.05.2006, 22:02 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=33700669&tid=1553519]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
66ms |
get tp. blocked users: |
1ms |
| others: | 177ms |
| total: | 322ms |

| 0 / 0 |
