|
|
|
использование unique для varchar
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. У меня тут вопрос на общие познания в mysql. Есть таблица id(int) link(varchar(200)) name(varchar) допустим. Мне надо, чтобы все ссылки были уникальными, ну, и первое, что пришло мне в голову - сделать поле link unique. На это начальник сказал, нельзя так делать, это varchar , при больших объемах данных плохо будет (честно искала в интернете, нигде не нашла, что плохо пользовать unique для varchar ), предложил завести еще один столбец, записывать туда хешированый линк и его делать уникальным... собственно вопрос: что оптимальнее и быстрее? unique для varchar или unique для его хеша? или разницы нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 17:52:49 |
|
||
|
использование unique для varchar
|
|||
|---|---|---|---|
|
#18+
В общем случае такого запрета, конечно, нет. Насколько оптимально использовать тот или другой вариант зависит от ваших локальных особенностей - количества записей, средней длины фактических данных в этом поле, выполняемых операций/запросов, требований по длительности выполнения запросов и т.п. Ваш вариант, скорее всего, потребует больше места для хранения, нежели вариант начальника. Но насколько это критично - решать вам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 17:59:40 |
|
||
|
использование unique для varchar
|
|||
|---|---|---|---|
|
#18+
спасибо) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 18:03:32 |
|
||
|
использование unique для varchar
|
|||
|---|---|---|---|
|
#18+
MargaritaM, кстати, уникальность хэша не гарантирует уникальность хэшируемого значения. Она лишь позволяет с довольно высокой вероятностью предположить , что если хэши отличаются, то и их прообразы тоже отличаются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 18:23:00 |
|
||
|
использование unique для varchar
|
|||
|---|---|---|---|
|
#18+
tanglirMargaritaM, кстати, уникальность хэша не гарантирует уникальность хэшируемого значения.Как раз гарантирует. А вот обратное не верно - уникальность исходных данных не гарантирует уникальности хэша.tanglirОна лишь позволяет с довольно высокой вероятностью предположить , что если хэши отличаются, то и их прообразы тоже отличаются.Да, при вычислении хэша по накопленным данным могут случиться коллизии, т.е. случаи, когда исходные строки разные, а хэши одинаковые. Также придется решить что делать в случае, если такие коллизии встретятся в будущем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 18:35:09 |
|
||
|
использование unique для varchar
|
|||
|---|---|---|---|
|
#18+
хм... да. это и имел в виду, а как начал писать, куда-то не в ту степь ушёл :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2013, 05:47:47 |
|
||
|
использование unique для varchar
|
|||
|---|---|---|---|
|
#18+
miksoft уникальность исходных данных не гарантирует уникальности хэша да, я знаю. В связи с этим, если в таблице будет очень много строк, можно ли применять CRC32? или все же надежнее будет мд5? miksoft Ваш вариант, скорее всего, потребует больше места для хранения, нежели вариант начальника. объясните пожалуйста почему? в моем понимании, если ко всем столбцам, которые у меня имеются добавить еще один "хеш" и сделать уникальным его ,а не строку, для которой он сделан... ну,это же займет больше места, чем без этого столбца и с уникальной строкой... данных храниться больше=>места занимает больше?.. ну, или, что очень вероятно, я чего-то не понимаю) другой вопрос, может просто запросы быстрее работать будут? miksoft зависит от ваших локальных особенностей - количества записей, средней длины фактических данных в этом поле, выполняемых операций/запросов, требований по длительности выполнения запросов и т.п записей много, предполагается больше 1 000 000, длина - ну средняя длина обычно ссылки), очень важна скорость выполнения, собственно поэтому и появилась идея с хешем , из-за опасения, что уникальность по текстовому полю, может замедлить работу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2013, 15:55:54 |
|
||
|
использование unique для varchar
|
|||
|---|---|---|---|
|
#18+
MargaritaMmiksoft уникальность исходных данных не гарантирует уникальности хэша да, я знаю. В связи с этим, если в таблице будет очень много строк, можно ли применять CRC32? или все же надежнее будет мд5?У MD5 будет значительно меньше коллизий, конечно. CRC32 дает 32 бита на выходе, а MD5 - 128 бит. На миллионе записей в CRC32 почти наверняка будет хотя бы коллизия, тогда как у MD5 еще остается запас в 96 двоичных порядков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2013, 16:13:26 |
|
||
|
использование unique для varchar
|
|||
|---|---|---|---|
|
#18+
MargaritaM, Быстрее будет unique для хэша, но очень ненамного. Но unique для хэша делать принципиально неправильно, потому как для РАЗНЫХ исходных строк может давать ОДИНАКОВЫЕ значения, потому ваш constraint работать будет не так, как constraint по исходному полю. Так что вывод — гнаться за мифической скоростью тут нельзя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2013, 20:55:51 |
|
||
|
использование unique для varchar
|
|||
|---|---|---|---|
|
#18+
MargaritaMmiksoft уникальность исходных данных не гарантирует уникальности хэша да, я знаю. В связи с этим, если в таблице будет очень много строк, можно ли применять CRC32? или все же надежнее будет мд5? miksoft Ваш вариант, скорее всего, потребует больше места для хранения, нежели вариант начальника. объясните пожалуйста почему? в моем понимании, если ко всем столбцам, которые у меня имеются добавить еще один "хеш" и сделать уникальным его ,а не строку, для которой он сделан... ну,это же займет больше места, чем без этого столбца и с уникальной строкой... данных храниться больше=>места занимает больше?.. ну, или, что очень вероятно, я чего-то не понимаю) другой вопрос, может просто запросы быстрее работать будут? miksoft зависит от ваших локальных особенностей - количества записей, средней длины фактических данных в этом поле, выполняемых операций/запросов, требований по длительности выполнения запросов и т.п записей много, предполагается больше 1 000 000, длина - ну средняя длина обычно ссылки), очень важна скорость выполнения, собственно поэтому и появилась идея с хешем , из-за опасения, что уникальность по текстовому полю, может замедлить работу. Ты все понимаешь правильно, просто мы естественно эффект замедления работы от увеличения длины записи, связанной с там, что добавляется ещё одно поле, в расчет не принимали. Потому что это сложно очень оценить. В общем тут так: поиск про новому индексу на хэш будет быстрее, за счет того, что хэш меньше строки (хотя ещё вопрос, на сколько) , но за счет того, что записи станет длиннее, чтение ее потенциально дольше и будет замедление. Какой в итоге будет суммарный эффект очень сложно сказать. С учетом того, что почти наверняка тебе надо будет ещё и по самой ссылке искать и индекс по ней делать, то предлагаю тебе забывать вообще о хэшах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2013, 22:54:28 |
|
||
|
|
start [/forum/topic.php?fid=47&msg=38339517&tid=1836402]: |
0ms |
get settings: |
5ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
44ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
26ms |
get tp. blocked users: |
1ms |
| others: | 202ms |
| total: | 301ms |
| 0 / 0 |
