Автор Тема: СУБД. Оптимальность хранения данных.  (Прочитано 21605 раз)

Valery Solovey

  • Hero Member
  • *****
  • Сообщений: 509
    • Просмотр профиля
СУБД. Оптимальность хранения данных.
« : Апрель 13, 2012, 09:30:08 am »
MS SQL неоптимально хранит данные, это тоже одна из причин большого объёма БД.
А какие СУБД хранят данные оптимальнее?

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД. Оптимальность хранения данных.
« Ответ #1 : Апрель 13, 2012, 09:34:54 am »
И какие критерии оптимальности? ::)

alexus

  • Гость
Re: СУБД. Оптимальность хранения данных.
« Ответ #2 : Апрель 13, 2012, 09:59:37 am »
MS SQL неоптимально хранит данные, это тоже одна из причин большого объёма БД.
А какие СУБД хранят данные оптимальнее?
Мне доводилось несколько раз портировать одни и те же данные под разные СУБД. С точки зрения хранения данных... БД под MS SQL или ASE (Adaptive Server Enterprise (Sybase)) объём БД был существенно больше (в разы), чем, например, под Firebird или SQL Anywhere (Sybase) или DB2 (IBM). Поэтому получить БД размером в несколько гигабайт на MS SQL проще, чем на многих других СУБД. При этом реакция на запросы у MS SQL не всегда лучшая (крайне не любит вложенные JOIN, например), хотя, в целом, по сравнению с бесплатными СУБД (Firebird, Postgress) и недорогими (Anyware) производительность MS SQL выше. В проприетарных СУБД от известных производителей картина с производительностью крайне неоднозначна и стандартное тестирование не делает картину более понятной, поскольку СУБД "заточены" на стандартные тестовые пакеты (TPC (см., например, http://www.tpc.org)). Ещё более трудной для понимания выглядит ситуация с Oracle, там избыточно (на мой взгляд) много оптимизационных настроек, поэтому понять и объяснить те или иные результаты тестирования производительности может только опытный орклоид (админ), коим я не являюсь.

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД. Оптимальность хранения данных.
« Ответ #3 : Апрель 13, 2012, 10:44:16 am »
А чем плох большой объем базы?
Ну т.е. будет 15 гигов на MS против 10 на Firebird. Что изменится, если MS работает все равно быстрее?
Почему вы считаете, что это неоптимально? Может они в другом выиграли, за счет избыточности хранения.

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

Valery Solovey

  • Hero Member
  • *****
  • Сообщений: 509
    • Просмотр профиля
Re: СУБД. Оптимальность хранения данных.
« Ответ #4 : Апрель 13, 2012, 10:49:25 am »
А DB2 сопоставима с MS SQL в производительности? На винде.

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД. Оптимальность хранения данных.
« Ответ #5 : Апрель 13, 2012, 11:17:12 am »
А DB2 сопоставима с MS SQL в производительности? На винде.

На этот вопрос невозможно ответить, т.к. очень много критериев оценки.
Это лучше на SQL форумах посмотреть. Там много информации на эту тему.

Если вы ищете СУБД под конкретную задачу, то составьте список критериев важных для вас и гуглИте  ;)

Могу сказать только, что у MS администрирование много приятнее, чем у Oracle или DB2. Плюс соотношение цена/качество очень хорошее.

И производительность кстати сильно от железа зависит. Т.е. если жесткий диск медленный, то нужно его менять, а не СУБД  :)

alexus

  • Гость
Re: СУБД. Оптимальность хранения данных.
« Ответ #6 : Апрель 13, 2012, 11:31:34 am »
А чем плох большой объем базы?
Есть такая категория вопросов, которые легко задать, но на которые... неудобно отвечать. Ваш вопрос из этой категории. Попробую ответить просто: мне не нравятся большие объёмы БД.
Позвольте и мне задать встречный вопрос из той же категории... А чем плоха низкая скорость выполнения запроса?...

Цитата: ilovb
Ну т.е. будет 15 гигов на MS против 10 на Firebird. Что изменится, если MS работает все равно быстрее?
Почему вы считаете, что это неоптимально? Может они в другом выиграли, за счет избыточности хранения.
А зачем мне быстрее?.. Моим пользователям и без того ждать приходится очень редко... Хотя сервера, как правило, старенькие и диски на них небольшие...

Цитата: ilovb
Если беспокоиться о месте на жестком диске, то там все равно еще транзакционный лог учитывать нужно, который при высокой нагрузке растет как на дрожжах)
Это Вам придётся учитывать (я с MS SQL не работаю), на Firebird, к примеру, никакого журнала транзакций нет.

alexus

  • Гость
Re: СУБД. Оптимальность хранения данных.
« Ответ #7 : Апрель 13, 2012, 11:33:16 am »
А DB2 сопоставима с MS SQL в производительности? На винде.
Не знаю, не мерил... Есть "независимые" организации, которые занимаются измерениями производительности, это к ним вопрос.

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД. Оптимальность хранения данных.
« Ответ #8 : Апрель 13, 2012, 11:56:55 am »
Позвольте и мне задать встречный вопрос из той же категории... А чем плоха низкая скорость выполнения запроса?...

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

Это Вам придётся учитывать (я с MS SQL не работаю), на Firebird, к примеру, никакого журнала транзакций нет.

Неужели? А как он транзакции выполняет?


alexus

  • Гость
Re: СУБД. Оптимальность хранения данных.
« Ответ #9 : Апрель 13, 2012, 12:49:29 pm »
Позвольте и мне задать встречный вопрос из той же категории... А чем плоха низкая скорость выполнения запроса?...
Ну например тем, что время реакции системы на действия пользователя зависит от скорости выполнения запроса.
Ну, и... чем же плохо большое время реакции системы?..

Цитата: ilovb
Это Вам придётся учитывать (я с MS SQL не работаю), на Firebird, к примеру, никакого журнала транзакций нет.
Неужели? А как он транзакции выполняет?
То есть?.. Вы думаете, что журнал нужен для выполнения транзакции?.. Нет, он нужен для восстановления БД после аварийных ситуаций. БД восстанавливается после резервного копирования (backup), а остальное (то, что было после последнего backup) накатывается по журналу транзакций.

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД. Оптимальность хранения данных.
« Ответ #10 : Апрель 13, 2012, 01:05:02 pm »
1. Тем что работать с такой системой не комфортно
p.s. Больше на эту цепочку не буду отвечать. ОК?

2. Мягко говоря это не совсем так.

alexus

  • Гость
Re: СУБД. Оптимальность хранения данных.
« Ответ #11 : Апрель 13, 2012, 01:30:52 pm »
1. Тем что работать с такой системой не комфортно
p.s. Больше на эту цепочку не буду отвечать. ОК?
Если не будете подобные вопросы задавать, то, конечно, ОК!

Цитата: ilovb
2. Мягко говоря это не совсем так.
Ну, так расскажите... Как будет совсем так...

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД. Оптимальность хранения данных.
« Ответ #12 : Апрель 13, 2012, 01:47:36 pm »
Ну, так расскажите... Как будет совсем так...

Вам рассказать как выполняются транзакции?

Вот тут есть ответы и по поводу журнала, и по поводу firebird:
http://www.sql.ru/forum/actualthread.aspx?tid=924197

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: СУБД. Оптимальность хранения данных.
« Ответ #13 : Апрель 13, 2012, 01:50:17 pm »
Есть какой-то тонкий негатив с вашей стороны... Или мне мерещится?
Может не будем в шахматы играть?
« Последнее редактирование: Апрель 13, 2012, 01:53:38 pm от ilovb »

alexus

  • Гость
Re: СУБД. Оптимальность хранения данных.
« Ответ #14 : Апрель 13, 2012, 01:54:51 pm »
Ну, так расскажите... Как будет совсем так...

Вам рассказать как выполняются транзакции?
Да, пожалуйста, если Вас не затруднит... (а вдруг!)  ;D

Цитата: ilovb
Вот тут есть ответы и по поводу журнала, и по поводу firebird:
http://www.sql.ru/forum/actualthread.aspx?tid=924197
Можно, получить от Вас полезную выжимку из этого трёпа?..
Другими словами, если Вам есть что сказать, то скажите, а если сказать нечего... тогда не надо...