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

Откуда:
Сообщений: 138
Привет всем!

Пожалуйста, люди, которые работали с SQL 2005, Oracle 10G, Cache 5, MySQL
укажите 5 сильных и 5 слабых сторон каждого продукта.

С уважением,
Юрий
30 апр 06, 15:28    [2617716]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
товарищщ Юра, сначала объясни пожалуйста зачем этому человеку (интересно есть такие?) писать про 40 разных сторон?
Я понимаю если помочь кому надо, но не удовлетворять же чьё-то празное любопытство
1 май 06, 00:48    [2618196]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение  [new]
Iura
Member

Откуда:
Сообщений: 138
Мне нужно выбрать оптимальную с точки зрения разработки и быстродействия базу данных.
1 май 06, 08:18    [2618281]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
на чем умеете на том и пишите. Это самый оптимальный вариант обычно оказывается.
1 май 06, 08:46    [2618288]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
Iura . Если бы была одна оптимальная база, то все другие вымерли бы.
Сильная сторона MS SQL - я его хорошо знаю!
1 май 06, 11:23    [2618371]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение  [new]
Iura
Member

Откуда:
Сообщений: 138
Мне нужен совет человека, который имел опыт написания баз данных на всех этих продуктах. Я уверен что их немного, но их мнение имеет большой вес.
1 май 06, 11:53    [2618406]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
Iura. Нет таких наверное. Хотя бы из-за того, что SQL 2005 и Oracle 10G довольно свежие продукты и вряд-ли кто-то успел изучить все их тонкости одновременно.
1 май 06, 12:05    [2618422]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение  [new]
Victor Metelitsa
Member

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


А почему хотите выбирать только по этим критериям?

Например, сколько заказчик готов заплатить за СУБД, хардварь и разработку БД?

Или, для начинающего разработчика, должен быть важен такой вопрос: разработчики для каких СУБД более всего востребованы? а какие получают наивысшую зарплату?
1 май 06, 13:06    [2618486]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Так, я предполагаю (не знаю, на самом деле, просто предполагаю), что ораклисты получают больше, чем мс-скулисты, а те намного больше, чем май-скулисты. Cache' - жуткая экзотика, труднее будет сменить работу на другую с Cache', а знания приобретаются не за один день и не за один год.

Это весьма важные соображения для программиста и админа.
1 май 06, 13:21    [2618500]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
Victor Metelitsa . Вы правы
1 май 06, 15:11    [2618626]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
И почему только я работаю по большей части с DB2?
;-)
1 май 06, 20:27    [2618987]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
Я не могу создать оптимальную структуру базы даннах на Oracle & SQL,
но полагаю, что ее возможно сделать на Cache.

То есть, мне нужно для каждого уникального ключа хранить несколько значений (список). Я не хочу вместе с каждым значением списка хранить его ключ. Это допустимо для небольших таблиц. Но если число записей более 1 000 000? Это просто не экономное использование памяти. Для кажой группы записей должно быть всего лишь одноразовое упоминание, к какому значению ID оно принадлежит.
1 май 06, 22:05    [2619129]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
Iura. Никто не запрещает Вам сделать таблицы без явно определенного индекса в MS SQL. Только вот выйдет вам это боком, когда вы соберетесь редактировать одну запись из "группы". Не путайте индексы и ключи! Ключ - это набор полей, который уникально определяет запись. Индекс - это структура, которая позволяет быстро найти запись по ключу. Бывают случаи, когда построение индекса невыгодно.
Миллион записей - это семечки.
1 май 06, 23:02    [2619217]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Iura
То есть, мне нужно для каждого уникального ключа хранить несколько значений (список). Я не хочу вместе с каждым значением списка хранить его ключ. Это допустимо для небольших таблиц. Но если число записей более 1 000 000? Это просто не экономное использование памяти. Для кажой группы записей должно быть всего лишь одноразовое упоминание, к какому значению ID оно принадлежит.


А за каждый сэкономленный мегабайт и ускорение на микросекунду дадут премию ;-)
1 май 06, 23:11    [2619228]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
Ой-ой! Надо быстро написать, пока пинать не начали! Это про индекс по первичному ключу. Можно ведь и другие индексы сделать.
1 май 06, 23:19    [2619234]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
serg_seak
Member

Откуда:
Сообщений: 1
Iura
Я не могу создать оптимальную структуру базы даннах на Oracle & SQL,
но полагаю, что ее возможно сделать на Cache.

То есть, мне нужно для каждого уникального ключа хранить несколько значений (список). Я не хочу вместе с каждым значением списка хранить его ключ. Это допустимо для небольших таблиц. Но если число записей более 1 000 000? Это просто не экономное использование памяти. Для кажой группы записей должно быть всего лишь одноразовое упоминание, к какому значению ID оно принадлежит.


Насколько я читал, что сама база Кэш не оптимальна, те занимает места намного больше чем РСУБД при наличии того объема данных... Это если разговор идет именно о критичности расхода памяти (места на дисках)...
1 май 06, 23:45    [2619281]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
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'е обещают гораздо более серьёзную компрессию.
2 май 06, 00:20    [2619331]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
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.
2 май 06, 10:15    [2619746]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
lura
То есть, мне нужно для каждого уникального ключа хранить несколько значений (список). Я не хочу вместе с каждым значением списка хранить его ключ. Это допустимо для небольших таблиц. Но если число записей более 1 000 000? Это просто не экономное использование памяти. Для кажой группы записей должно быть всего лишь одноразовое упоминание, к какому значению ID оно принадлежит.

У меня тока 2 вопроса
1. Вы давно ли начали этим делом баловаться? В смысле - проектированием БД :)
2. Кто вам сказал, что так, как вы почему-то не хотите, делать нельзя? Сон был в четверг? Или кто есть еще умнее вас? :))

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

Давайте лучше постановку задачи опишите чтоли, сколько записей, сколько сущностей, чего делать и т.д. А то сразу - кэш, оракл, массивы.... :))

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

Откуда: Тюмень
Сообщений: 2559
tygra
Я боюсь подумать, но вы что, вправду считаете, что если вы явно не задаете ссылку на родительский объект для каждой записи, ее там и нет? А как тогда записи выбираются - чудо каждый раз БД творит?


Не нужно чудес. Схема
create table master(
master_id primary key
...
)
create table slave(
slave_id primary key.
master_id foreign key
...
)
может быть представлена и по-другому. Вместо того, чтобы каждая запись slave ссылалась на запись в master посредством master_id, (master:1 <- slave:N), запись в master может ссылаться на массив записей slaves (master:1 -> slaves:1). Это легко вообразить для не-SQL-СУБД.

Хотя... экономия места всё равно весьма спорна. Если упаковывать массив плотно для всей таблицы, можно замучаться с управлением памятью, а если для каждого master_id выделять минимум экстент для его массива slaves, для выигрыша надо, чтобы эти массивы были весьма и весьма большие, а тогда, наверное, и записи в массивах будут достаточно широкие, и выигрыш на отсутствии "master_id foreign key" грошовый.
2 май 06, 15:00    [2621282]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
vadiminfo
Member

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

Это легко вообразить для не-SQL-СУБД.


Да и в Оракле представить моно легко (вложенные таблицы). Хуже представить как это потом запросы это прокорявит, када надо будет с этой инфой работать. Не та эта плата за экономию на диске. Логикой платить за физику что-то ломает без каких-то особых причин.
2 май 06, 16:01    [2621610]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

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

Да и в Оракле представить моно легко (вложенные таблицы). Хуже представить как это потом запросы это прокорявит, када надо будет с этой инфой работать.


А ты реально это пробывал делать?
2 май 06, 16:34    [2621817]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
гость гостевый
Guest
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...
2 май 06, 17:02    [2621972]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
Iura
и он хотел сэкономить байты на master_id в таблице slave.

Кажись есть похожая возможность у Oracle.

Если не ошибаюсь, у Oracle есть даже два варианта для этой возможности. Можно сделать INDEX CLUSTER, а можно - INDEX-ORGANIZED TABLE с ключом COMPRESS. Хотя лень лезть в доку проверять :)
2 май 06, 21:30    [2622809]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
S.G.
Member

Откуда: cartoon network
Сообщений: 30611
Iura
Я не хочу вместе с каждым значением списка хранить его ключ. Это допустимо для небольших таблиц. Но если число записей более 1 000 000? Это просто не экономное использование памяти.


Оптимизация - это в принципе хорошо. Оптимизация ради оптимизации- это плохо. Например:
- Нам достаточно, чтобы запрос выполнялся за секунду- две. Он выполняется за полсекунды, на реальных данных. Незачем его оптимизировать, чтобы он выполнялся быстрее.
- У нас диск в 40 ГБ, а БД занимает около 1 ГБ. Тогда нам незачем экономить на индексах, байтах или указателях. Что мы будем делать с оставшейся памятью? Унесем домой?

В таких случаях как выше- имхо надо сосредоточиться не на экономии которая достигается за счет усложнения, а на понятных, стандартных решениях.
2 май 06, 22:02    [2622848]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 19   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить