Ой, а как-же это сделать-то?

[Андрей Барыкин]

Сообщение от boric

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

Сообщение от shadx

У мну например есть БД, в ней 60К товаров (парс Я.Маркета). У каждого товара есть описание состоящее из поле + значение. Для одного товара, таких полей может быть от 10 до сотни. Если хранить описания в тупую = одна строка в таблице |айди товара|айди поля|значение, то записей в таблице становится больше пары мульенов. Все баста мускул повесился. А если такую запись свернуть к строке {айди поля;значение|айди поля;значение|...} то все живет и радуется. НО!!! по описаниям никакого поиска не производится только красиво выводится пользователю.

Ну собсно о таких случаях и говорил.
Хотя че, реально Мускуль от пары миллионов записей вешается? Это ж не серьезно)))

[shadx]

Андрей Барыкин, если шаред хостинг, то легко.

[boric]

Андрей Барыкин,

Хотя че, реально Мускуль от пары миллионов записей вешается? Это ж не серьезно)))

Если рассматривать нормальную выделенную машинку Intel Duo 3GHz/RAM4GB, то у меня начались проблемы на 30 миллионах записей. Порог проблемности - около 20 миллионов. Пришлось очень тщательно подходить к оптимизации. У меня к этой таблице использовался достаточно сложный запрос с агрегацией, а выполняться он должен за секунду-две. Частично помогло разбитие таблицы на партиции (появились в версии 5.1). Проблема была даже в переносе на боевой сервер. Через mysqldump импортировать не получилось из-за очень долгого импорта и большой нагрузки на боевой сервер. Пришлось тупо файлы БД скопировать и сделать проверку таблиц.

Да, рекомендую под индексы выделять буферы так, чтобы индексные файлы целиком туда влезали. В моем случае я отвел под этот буфер 1.5 Гига. А сейчас планирую машинку на топовом интеловском проце и памяти оперативной возьму 16-32 гига - на сколько денег хватит. Ну и hdd wd raptor на 600гиг за 8000 руб. наверно возьму. А куда деваться? Иначе обработка таких таблиц будет идти не сутки например, а месяц.

[shadx]

boric, в свое время при таких же граблях пришлось сваливать на MSSQL ибо объем БД перевалил за 50Гб

[Jooz]

shadx, лучше уж на оракл, если расчеты жесткие

[boric]

А postgree в смысле работы с большими объемами данных лучше mysql будет?

[Алексей Барыкин]

Жизнь после MySQL: выбираем замену для популярной СУБД
http://www.xakep.ru/post/55801/

[boolevar]

Сообщение от shadx

А если такую запись свернуть к строке {айди поля;значение|айди поля;значение|...} то все живет и радуется. НО!!! по описаниям никакого поиска не производится только красиво выводится пользователю.

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

[shadx]

boolevar, сворачивается и разворачивается строчка очень быстро можно даже простым сплитом все сделать.
А по поводу чего выбирать MSSQL или Oracle. То тут финансовая часть. MSSQL дешевле обойдется чем Оракла в формате веб сервера (то есть с неограниченым числом подключений). А так согласен Оракла куда приятнее в планее администрирования и тюнинга и разработки, один SpotLight чего стоит.

[Андрей Барыкин]

Сообщение от boric

Андрей Барыкин,
Если рассматривать нормальную выделенную машинку Intel Duo 3GHz/RAM4GB, то у меня начались проблемы на 30 миллионах записей. Порог проблемности - около 20 миллионов...

Я думаю, тут еще надо учитывать, какие записи. Есть записи по 50 полей, и почти все строковые с большой длиной, а может запись в 3 поля, и там тока int.

Сообщение от shadx

А по поводу чего выбирать MSSQL или Oracle. То тут, кому что больше нравится...

поправил. Имхо

з.ы. Кстати, хочу прорекламировать имхо один из самых лучших ресурсов по БД: sql.ru
Там есть топики по каждой СУБД; есть раздел "Сравнение СУБД", где вам доходчиво объяснят, что для 99% задач надо выбирать не Оракл\МССКЛ\самая крутая СУБД, а то, что вы лучше знаете...
+ разделы по языкам программирования
про работу\вакансии
очень веселый раздел потрепаться
Сидит очень много умных людей по БД.