откуда такие дикие цифры? не поленился, сделал таблицу: Код (Text): Модели: model_id int 11 model name varchar 50 заполнил, так сказать, названиями (текст разной длины), как и заказывали ровно 25000 штук: PHP: for($i=0; $i<25000; $i++) { $res = md5(rand(1,25000)); $res = substr($res, 0, rand(10, 32)); // - название модели :) execsql("insert into model (model_name) values ('".$res."')"); } делаю выборку из 2000 строк, а за одно считаю совпадения PHP: for($i=0; $i<2000; $i++) { $res = md5(rand(1,25000)); // - название из xml $res = md5(rand(1,25000)); $arr = opensql("select count(model_id) from model where locate(model_name,'".$res."')"); if(!empty($arr)) { if($arr[0][0] > 0) $ac++; else $nc++; } } echo "<br>Совпадений (".$ac."), несовпадений (".$nc."), время ".($nd-$st)." сек."; Совпадений (998), несовпадений (1002), время 20 сек. Совпадений (1005), несовпадений (995), время 21 сек. итого: прайсов от 40 магазинов (40*20 сек. ~ 15 мин.), как по мне - приемлемое время для такого кол-ва информации... ps или я чего не понимаю? может где и ошибся, сегодня голову задурили...
То есть модели вводит человек, в обязанность которого следить за вменяемостью данных. ок. =substr не пойдет, придется искать лайком. как костыль пойдет вынесение бренда в отдельную таблицу и поиск его в добавляемом значении, а дальше where brand_id=$bid and locate( разница в том, что бренды можно запихнуть в массив все (влезут в память) можно и модель (х820) отдельно выносить, но это уже как будет удобнее по месту.
code_model в таблице Модели и Товары делать каким ключем уникальным, первичным или просто индекс? какая разница между этими типами ключей.
первичным - он же уникальный в моделях. двух одинаковых моделей не должно быть. в товарах - отдельно надо первичный как номер записи и обычный для модель_ид - их же будет много одинаковых в таблице.
если первичный, то auto_increment надо ставить? или оно при добавлении новых моделей будет работать как auto_increment?
вот читал, что если часто в таблице удалять и добавлять или изменять записи, то наличие индексов только тормозит эти действия. Правда? источник http://ict.edu.ru/ft/001779/5-3.shtml
да. Но это несравнимо с потерями при поиске при их отсутствии. Если у тебя в таблице еще 10 полей, по которым ты не ищешь, то на них ставить индексы не надо.
как с точки зрения производительности будет лучше сделать запрос update model set code_output=1 where model INNER JOIN data_proba ON model.code_model = data_proba.code_model или update model, data_proba set code_output=1 where model.code_model = data_proba.code_model експерементировать немогу. нет возможности. запрос SELECT model.code_model FROM model INNER JOIN data_proba ON model.code_model = data_proba.code_model выполняется 0.1066 сек простой запрос update model set code_output=1 выполняется 2,135 сек время выполнения запросов для data_proba 12 000 записей для model 25 000 как посчитать время выполнения для update из where model.code_model = data_proba.code_model?
2.135/25000=0.000085 время update одной записи 25 000 *0.1066 = 44,4 мин на сравнение model.code_model = data_proba.code_model всего 44,4 мин. + 2,135 сек. правильно посчитал?
нет. полная каша. просто тестируй. индексы где расставлены? распиши алгоритм, что-то у тебя еще не так.
model code_model primary товары code_data primary code_model index правильно? как с точки зрения производительности будет лучше сделать запрос update model set code_output=1 where model INNER JOIN data_proba ON model.code_model = data_proba.code_model или update model, data_proba set code_output=1 where model.code_model = data_proba.code_model и сколько примерно он будет исполнятся?
ну НЕ ОБНОВЛЯЮТСЯ данные по часу :!: в таких простых запросах с таким количеством данных, при правильной базе. у меня, в одной из баз (правда не на MySQL, а на InterBase): Таблиц: 27 Представлений: 7 Процедур: 99 Триггеров: 3 Индексов: 60 ~ 2 млн. записей, на диске ~ 250Мб построен, с помощью процедур (ну так захотелось мне :roll: ), анализ результатов сдач экзаменов/тестов с определением правильных ответов для каждого вопроса по оценкам (с помощью статистики и частично теории вероятности). так вот, перерасчет одного теста (тестов в базе чуть больше 500) Код (Text): Query Time ------------------------------------------------ Prepare : 0,00 ms Execute : 6 775 000,00 ms (1h 52m 55s 0ms) Avg fetch time: 0,00 ms Operations ------------------------------------------------ Read : 99 440 Writes : 1 127 Fetches: -1 831 288 380 Enchanced Info: +--------------------------+-----------+-----------+-------------+---------+---------+---------+ | Table Name | Records | Indexed | Non-Indexed | Updates | Deletes | Inserts | | | Total | reads | reads | | | | +--------------------------+-----------+-----------+-------------+---------+---------+---------+ | PS| 95 | 23967 | 0 | 0 | 95 | 0 | | Q| 52768 | 50928 | 0 | 2596 | 0 | 0 | | QT| 466238 | 53227691 | 0 | 8774 | 9917 | 10263 | | Q_ONLY| 28801 | 2605077 | 0 | 0 | 0 | 336 | | S| 18863 | 210996 | 0 | 0 | 0 | 0 | | SQ| 662140 | 40805409 | 0 | 0 | 0 | 0 | | ST| 343698 | 3601767 | 0 | 15493 | 11480 | 13776 | | ST_ORIG| 346017 | 13776 | 0 | 0 | 0 | 0 | и т.д. а теперь сравни мои цифры с думаешь твой запрос будет час выполняться?
как правильно создавать представления? делаю так CREATE VIEW new_table AS SELECT ip FROM coment выдает ошибку #1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'VIEW new_table AS SELECT ip FROM coment' at line 1
Ipolit, ну так что я неправильно сделал? Модели (25000) код_модели (primary index) название_модели (текст) код_наличия в продаже (int) 0 - нет в продаже, 1 - есть в продаже Товары (114000) код_товара (primary index) название_товара (текст) код_модели (index) Делаю запрос update model, data_proba set code_output=0 where model.code_model != data_proba.code_model должно обновить около 20000 записей. Ответа дождатся не могу . Сервер БД "ложится" Вы помню приводили пример с записями на основе md5. Если не трудно попробуйте запрос у себя. Может сервак физически не тянет.
[sql]update model set code_output = 0[/sql] Естественно. Обьясни, какую функцию у тебя выполняет таблица товаров? Что она хранит? Русскими связными словами обьясни.
не силен в сленге, это что? хмм... тогда очень коротко в двух словах: есть такая штука "Computerized Adaptive Testing (CAT)", где следущий вопрос (второй) выдается в зависимости от ответа на предыдущий (первый), т.е. ответил правильно - вопрос сложнее, ответил неправильно - вопрос легче... не зная правильный ответ на "первый" вопрос можно с некоторой вероятностю получить его (т.е. определить правильный) учитывая сложность "второго" вопроса... ps хотя доказывать никому и ничего не собираюсь, верить или не верить это личное дело каждого человека.