Т.е. мы можем указать слово собака, скрипт пробегается по всем переводам и заполняет таблицу с названием собака.
Но задача состоит в том что бы отсеивать повторяющиеся значения переводов т.е. у нас есть таблица -собака, в ней есть перводы типа энимал и дог, когда скрипт пробегается по слову кошка он получает перводы с сайта и каждый перевод проверяет по уже существующим таблицам. Таким образом пробегаясь по слову кошка скрипт получит перевод кэт и энимал т.к. энимал уже существует в таблице собака этот перевод не будет записан в таблицу кошка. И вроде бы все ничего, но количество таблиц постоянно ростет и увеличивается количество значений, в силу этого простая проверка по всем таблицам растягивается уже на 10ки минут как это все можно оптимизировать, что бы ускорить проверку?
Спустя 19 минут, 45 секунд (21.08.2011 - 10:54) kirik написал(а):
| Цитата (Guest @ 21.08.2011 - 03:34) |
| как это все можно оптимизировать, что бы ускорить проверку? |
Избавиться от множества таблиц. Это большая ошибка считать что нагрузка уменьшится, если увеличить количество таблиц.
| Цитата (Guest @ 21.08.2011 - 03:34) |
| повторяющиеся значения переводов т.е. у нас есть таблица -собака, в ней есть перводы типа энимал и дог, |
Так это таблицы переводов или что? В любом случае - можете создать уникальный индекс, тогда выборка будет происходить очень быстро, и БД не даст вставить повтор.
Как по мне, так всё очень запутано написано, чтобы можно было делать предложения по оптимизации..
Спустя 7 минут, 22 секунды (21.08.2011 - 11:01) Guest написал(а):
идея состоит в следующем для того что бы произвести выборку всех переводов одного слова нужно обратиться к таблице перевода этого слова, а не к общей базе с полумиллионым количеством строк. то же и со сравнением новых и уже существующих переводов думаю скрипту проще запрашивать информацию не сколько раз из разных таблиц чем пробегать по одной но много томной или нет?
Спустя 5 минут, 49 секунд (21.08.2011 - 11:07) Guest написал(а):
а можно ли уникальным индексом сделать поле с текстовм значением перевода, т.е. не порядковый номер в таблице а именно перевод, и еще вопрос уникальными могут быть два поля в таблице?
Спустя 8 минут, 5 секунд (21.08.2011 - 11:15) kirik написал(а):
| Цитата (Guest @ 21.08.2011 - 04:07) |
| а можно ли уникальным индексом сделать поле с текстовм значением перевода |
А вы попробуйте)
| Цитата (Guest @ 21.08.2011 - 04:07) |
| уникальными могут быть два поля в таблице? |
Хоть десять. Ещё есть такая штука как "многостолбцовый" индекс, и он тоже может быть уникальный.
| Цитата (Guest @ 21.08.2011 - 04:01) |
| думаю скрипту проще запрашивать информацию не сколько раз из разных таблиц чем пробегать по одной но много томной или нет? |
При условии грамотной расстановки индексов даже очень большая табличка может быть производительной.
Это всё тонкости, и о них можно почитать в талмуде по используемому движку БД. Так же есть SQL оператор EXPLAIN который покажет насколько тяжело СУБД найти нужную строку в таблице.
Спустя 2 минуты, 44 секунды (21.08.2011 - 11:18) Guest написал(а):
все понятно спасибо большое
Спустя 3 часа, 27 минут, 20 секунд (21.08.2011 - 14:45) Guest написал(а):
kirik
будьте добры подскажите а можно ли решить задачу следующим образом за место того что бы каждый новый перевод проверять на наличие в таблице, собрать все новые переводы поместить их во временную таблицу, столбцам с переводом в обеих таблицах назначить уникальность ключей, а затем сделать выборку через join по этим двум таблицам т.е. вернуть id тех строк чьи переводы совпали с теми которые уже содержатся в основной таблице. Может быть так более производительно получится , насколько мне известно mysql работает быстрее чем php? как поступить?
будьте добры подскажите а можно ли решить задачу следующим образом за место того что бы каждый новый перевод проверять на наличие в таблице, собрать все новые переводы поместить их во временную таблицу, столбцам с переводом в обеих таблицах назначить уникальность ключей, а затем сделать выборку через join по этим двум таблицам т.е. вернуть id тех строк чьи переводы совпали с теми которые уже содержатся в основной таблице. Может быть так более производительно получится , насколько мне известно mysql работает быстрее чем php? как поступить?
Спустя 1 минута, 37 секунд (21.08.2011 - 14:47) Guest написал(а):
или это одно и то же получится если общей таблице с переводами назначить уникальный ключ и каждый новый перевод проверять отдельно?
Спустя 6 часов, 55 минут, 20 секунд (21.08.2011 - 21:42) kirik написал(а):
| Цитата (Guest @ 21.08.2011 - 07:45) |
| насколько мне известно mysql работает быстрее чем php? |
Где вам такое сказали? БД всегда является слабым местом в выысоконагруженных проектах.
Я всё же не уверен что вам именно нужно, но мне кажется что вопрос решается 3-мя табличками:
word:
id | word
translate:
id | translate
word2translate:
word_id | translate_id
В таблице word складываем оригинальные слова [id - автоинкримент, word - уникальный]; в табличку translate складываем переводы (не важно чего) [id - автоинкримент, translate - уникальный]; в табличку word2translate хранит "ассоциации" данных из первой таблички к данным из второй (один ко многим). В общем типичная трёхтабличная архитектурка)
Спустя 1 час, 45 минут, 26 секунд (21.08.2011 - 23:27) Guest написал(а):
хмммм немного не то, фишка в том что значения перевода могут повторяться т.е. могут быть синонимы которые будут попадать переводом или синонимами к другим словам. такие повторения нужно отсеять сразу что бы база не разрослась и на одно слово были индивидуальные значения переводов
поэтому я сделал почти как описали вы
word:
id | word
translate:
id | id_word | translate
вот так не знаю только насколько это правильно
вопрос заключался вот в чем -у нас есть выше описанная структура translete во второй таблице уникальный я получаю новую партию переводов и каждое слово в переводе проверяю на наличие во второй таблице (что бы избежать повторений)- на одно слово идет один запрос нагрузка коласальная, но может быть более правильными было бы сделать так
получить партию переводов создать временную таблицу типа id| new_translet
где new_translet будет уникальным и затем посредством join отобрать id временной таблицы тех значений которые не совпали. В результате получим набор переводов которых еще нет и соответственно перенесем эти новые переводы в таблицу translate
можно ли так делать т.е. технически это будет грамотно или нет?
поэтому я сделал почти как описали вы
word:
id | word
translate:
id | id_word | translate
вот так не знаю только насколько это правильно
вопрос заключался вот в чем -у нас есть выше описанная структура translete во второй таблице уникальный я получаю новую партию переводов и каждое слово в переводе проверяю на наличие во второй таблице (что бы избежать повторений)- на одно слово идет один запрос нагрузка коласальная, но может быть более правильными было бы сделать так
получить партию переводов создать временную таблицу типа id| new_translet
где new_translet будет уникальным и затем посредством join отобрать id временной таблицы тех значений которые не совпали. В результате получим набор переводов которых еще нет и соответственно перенесем эти новые переводы в таблицу translate
можно ли так делать т.е. технически это будет грамотно или нет?
Спустя 9 минут, 46 секунд (21.08.2011 - 23:37) neadekvat написал(а):
word:
id | word
translate:
id | id_word | translate
При этом во второй таблице
id_word | translate
является составным "уникальным".
При добавлении запрос выглядит так:
INSERT IGNORE ...
А перевод должен быть оформлен по одному правилу - т.е. в нижнем регистре.
Можно попробовать, а дальше по ситуации смотреть - быстрее это или не быстрее. Но проще - точно.
id | word
translate:
id | id_word | translate
При этом во второй таблице
id_word | translate
является составным "уникальным".
При добавлении запрос выглядит так:
INSERT IGNORE ...
А перевод должен быть оформлен по одному правилу - т.е. в нижнем регистре.
Можно попробовать, а дальше по ситуации смотреть - быстрее это или не быстрее. Но проще - точно.
Спустя 8 минут, 26 секунд (21.08.2011 - 23:46) kirik написал(а):
| Цитата (Guest @ 21.08.2011 - 16:27) |
| могут быть синонимы которые будут попадать переводом или синонимами к другим словам. такие повторения нужно отсеять сразу что бы база не разрослась и на одно слово были индивидуальные значения переводов |
Ээм..
Давайте с примером из вашего поста: собака [dog, animal], кошко [cat, animal].
При использовании вышеописанного способа с тремя табличками, мы получим следующие данные по таблицам:
word:
id | word
------------
1 | собака
2 | кошка
translate:
id | translate
---------------
1 | dog
2 | animal (т.к. колонка translate уникальная, имеем всего один перевод на оба слова)
3 | cat
word2translate:
word_id | translate_id
----------------------
1 | 1 (собака - dog)
1 | 2 (собака - animal)
2 | 3 (кошка - cat)
2 | 2 (кошка - animal)
При описаной таблице вами, у нас будут дублироваться данные в поле translate второй таблицы (в случае с кошками - два раза будет animal), а если это поле будет уникальным, как вы сказали, то вы не сможете назначить кошке перевод animal (т.к. animal уже существует для собаки).
Возвращаясь к нашим трём табличкам, рассмотрим что будет происходить при добавлении переводов:
- берём слово и его переводы
- добавляем слово в таблицу word (получаем word_id)
- проверяем, есть ли перевод в таблице translate.
+ есть - просто берём его translate_id
- нет - вставляем в таблицу translate новый перевод, забираем translate_id
- добавляем в третью таблицу (word2translate) новую пару word_id:translate_id
Как-то так..
Спустя 4 минуты, 12 секунд (21.08.2011 - 23:50) Guest написал(а):
ооой голова уже не варит спасибо за ответы я подумаю отпишусь
Спустя 17 секунд (21.08.2011 - 23:50) neadekvat написал(а):
Позволю себе добавить, почему вариант kirik'a лучше:
1. Можно сделать двусторонний перевод. В случаи с двумя таблицами, перевод будет работать только в одну сторону.
2. Размер базы будет намного меньше.
1. Можно сделать двусторонний перевод. В случаи с двумя таблицами, перевод будет работать только в одну сторону.
2. Размер базы будет намного меньше.