|
|
|
UPDATE vs DELETE & INSERT
|
|||
|---|---|---|---|
|
#18+
Есть таблица с несколькими полями, без первичного ключа. По ходу задачи необходимо обновлять некоторые поля в строке таблицы. т.к. первичного ключа нет (да он бы непригодился в данном случае), то апдейт происходит по нескольким фильтрам: update table set count='a' where id='b' and date='c' and hour='e' Мне кажется, что такой расширенный набор фильтров (where) способствует долгому выполнению запроса. Решился на преобразование предыдущего запроса в: delete from table where id='b' and date='c' и insert into table set count='a', id='b', date='c', hour='e' Поидее должно быть быстрее, но кажется не намного. Какие вообще есть способы решения данной проблемы? Когда необходимо обновление конкретного столбца в зависимости от других НЕСКОЛЬКИХ? Может есть финт заведения ключей и проч.. Подскажите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2004, 12:15 |
|
||
|
UPDATE vs DELETE & INSERT
|
|||
|---|---|---|---|
|
#18+
Я создал индексное поле. Его содержимое формирую при добавлении новой записи - склеиваю значения 3х полей. т.е. получается уникальный ключ: param1|param2|param3|double_key| value1|value2|value3|value1value2value3| Но не для всех таблиц возможно создать индекс по трем полям. если необходимо учитывать текстовове поле, размером более 255 символов, то я немогу использовать в качестве индекса поле типа char. Какие есть варианты решения? Может быть имеет смысл преобразовывать текст в некую цифровую последовательность.. Но как? Или есть совершенно другое решение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2004, 12:16 |
|
||
|
UPDATE vs DELETE & INSERT
|
|||
|---|---|---|---|
|
#18+
А нельзя добавить поле для хранения первичного ключа? Или изменение структур недопустимо? А длинное текстовое поле, наверное, можешь свернуть какой-нить функцией типа md5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2004, 15:42 |
|
||
|
UPDATE vs DELETE & INSERT
|
|||
|---|---|---|---|
|
#18+
А нельзя добавить поле для хранения первичного ключа? во втором сообщении я описал, что добавил поле double_key. это первичный индекс, который я и использую в выражении update ... where double_key='value1value2value3' т.е. я заменил запрос типа: update table set field='value0' where field1='value1' and field2='value2' and field3='value3' на update table set field='value0' where double_key='value1value2value3' по моим подсчетам, это должно быть намного быстрее, т.к. число фильтров в выборке уменьшилось до одного, и поле является индексом. НО! проблема в том что это поле может быть длинным. более 255 символов. А длинное текстовое поле, наверное, можешь свернуть какой-нить функцией типа md5. я думал о ней. но насколько мне известно, она не такая уж и быстрая функция.. какие есть еще предложения по сворачиванию? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2004, 10:38 |
|
||
|
UPDATE vs DELETE & INSERT
|
|||
|---|---|---|---|
|
#18+
Скорость выполнения ф-ии md5 не важна, если полученное значение хранить в отдельном поле записи. Выполняться такая ф-я будет только при изменении твоего длинного текстового поля - т.е. не "на лету" в процессе каких-то серийных действий, а на фоне юзерской интерактивной работы, когда собственно скорость её выполнения несущественна. а по поводу первичного ключа - может стоит все-таки его не формировать из нескольких полей, а вести это поле с помощью автоинкремента? Ведь главное - это обеспечить его уникальность? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2004, 13:45 |
|
||
|
UPDATE vs DELETE & INSERT
|
|||
|---|---|---|---|
|
#18+
а по поводу первичного ключа - может стоит ... вести это поле с помощью автоинкремента? смысл в этом поле? я хочу обновить данные. какие именно - определяется НАБОРОМ фильтров. в момент обновления я знаю только эти значения. не делать же мне выборку, для того что бы узнать значение автоинкрементного поля, а потом сделать апдейт для этого поля.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2004, 14:02 |
|
||
|
|

start [/forum/topic.php?fid=47&fpage=685&tid=1855121]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
143ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 212ms |
| total: | 433ms |

| 0 / 0 |
