[Няшный велосипед][MySQL] Что медленней: запрос к сотне простых, или одной сложной таблице?

А key-value тебе не подойдет? http://code.google.com/p/redis/wiki/README

На мелких таблицах вроде старый mysql 3.23 всех рвал. Думаю, 5-ка будет не намного хуже.

>http://code.google.com/p/redis/wiki/README

Быстрая, но скорость тут не критична. Боюсь, будет попросту неудобно - слишком много параметров.

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

В случае со всеми(~480) таблицами - нужно лишь проверить истинно или ложно значение единственной ячейки определённого столбца. Истина будет примерно в 1/4 случаев, только совпавшие таблицы придётся перечитывать.

Руки тянутся написать это на плюсах... Хочется верить что мускуль будет много быстрее :)

> скорость тут не критична

Ты ж сам говорил, что надо быстрее...

Интересно. Опиши структуру данных.

Это желательно ;) Но если выбирать между "неудобно + всего за несколько миллисекунд" и "удобно + всего за пару секунд", я выберу второе.

>Единовременно нужно обслуживать 1-3 пользователей. На серваке 2 четырёхядерных Оптерона.

В этих условиях - хоть в файлах хранить и в цикле искомое значение искать. Оптимизацией нужно заниматься, когда у тебя хотя бы сотня запросов в секунду идёт, серьёзной оптимизацией - когда 1000 в секунду :)

|target|pass 1|pass 2|pass 3|pass 4|pass 5|pass 6|pass 7|pass 8|pass 9|pass 10|res|
------------------------------------------------------------------------------- --------------------
| 1 |true |true |false |false |false |false |false |true |false |false |true|
| 2 |true |true |false |false |false |false |false |true |false |true |
| 3 |true |true |true |true |false |true |false |true |true |true |
| 4 |true |true |true |false |true |false |true |true |false |true |
| 5 |true |true |false |false |false |false |false |true |false |false |
...
|result|true |true |false |false |false |false |false |false |false |false |


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

Вот примерно таких таблиц у меня наберётся с пол тысячи. Нужно найти таблицы с false в res, и вернуть их идентификаторы. Дальше - проще: проверить значение в строке result(последняя) определённого столбца и вернуть номера строк, содержащих false.

Это прекрасно! Это открывает путь новому велосипеду :) Шучу, конечно... Будет быстро работать на мускуле - перенесу на sqlite для настольной версии.

Реализация с огромным количеством SQL запросов вида "SELECT `pass 7` FROM myTable WHERE target=3" будет работать гораздо медленнее чем через собственную наколенную неSQL базу данных, которая сделана специально для таких простых выборок.

Не доконца понятны начальные условия.
Если шесть сотен табличек завязаны реляциями, то жопа. Проверка тригерами целосности сцылок сожрет все. Лучше одну но Б О Л Ь Ш У Ю.

>Реализация с огромным количеством SQL запросов вида "SELECT `pass 7` FROM myTable WHERE target=3" будет работать гораздо медленнее чем через собственную наколенную неSQL базу данных, которая сделана специально для таких простых выборок.

Приятель оказался столь реактивным, что часть софтины уже работает :) Скоро узнаем о скорости.

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

С другой стороны, если верить Крону, тормозов я не замечу.

>если верить Крону, тормозов я не замечу.

Связь крона и тормозов в студию.

> имею около шести сотен простых(13x40) табличек

Ужас. Придется вам брать частные уроки баз данных. Дорого.

Выше по треду.

Не придётся, приятель, не придётся. Я на этом только заработаю.

Не, я не планирую заниматься БД в будущем.

>Вот примерно таких таблиц у меня наберётся с пол тысячи. Нужно найти таблицы с false в res, и вернуть их идентификаторы. Дальше - проще: проверить значение в строке result(последняя) определённого столбца и вернуть номера строк, содержащих false.

Построй вьюверы и не парься.

У тебя такая структура БД, что аж просит, чтобы ее нормализовали. Особенно pass 1 ... pass 10 пахнут за версту.

Запомните, ребята, такое: MySQL, когда у него реляции между сложносоставленными таблицами в количестве больше трех (навскидку), или когда строчки для результата очень длинные сами по себе (например, 30 полей типа TEXT или что-то в этом роде), превращается в тыкву. И RDBMS из него тогда такой же, как и из тыквы.

>Построй вьюверы и не парься.

Я в верном направлении копаю: http://dev.mysql.com/doc/refman/5.0/en/create-view.html ?

Не знаю как. Может завтра, если в лоб не удастся решить, возьмусь за документацию. http://www.mysql.ru/docs/gruber/ показалось слишком нудным, хотя и довольно понятно. Но нужно проспаться :)

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

Вобщем, в школу НАДО ходить :)

Тогда ты будешь писать более грамотно на русском )))

Да, неплохо бы изучить. Но сроки поджимают. Раз нагрузка почти никакая, я могу себе позволить сделать это максимально простым и приспособенным для расширения способом. Хоть это и медленно(вопрос, кстати). Ещё даже не знаю что понадобится через неделю.

а где игра?

Если я правильно понял исходные требования, то твои 600 таблиц легко превращаются в три: две - словари target(int) и pass(int), 3-я - их пересечение targ_x_pass(int,int) без всяких bool.