|
|
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
Добрый день. Есть таблица, в ней много полей(300) и много данных(20М) (поля в основном это FK на справочники). Помимо FK в таблице несколько varchar(255) полей, типа ФИО, номера телефона и т.д. Вопрос в следующем, будет ли какой либо профит от переноса поля в отдельную таблицу(то есть отразится ли это положительно на скорости поиска инфы по этому полю или там данные будут ?лучше? хранится)? Поле индексное, его заполненность относительно всех строк на данный момент >80%, в худшем случае будет 50% думаю. И будет ли выигрыш от того, что поле varchar переделать в int?(знаю что индекс по полю int работает быстрее, но стоит ли игра свеч?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 10:30 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
VARCHAR(255) в INT переделать может быть непросто... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 11:13 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
YuRock, Переделать не проблема (если быть конкретным, это поле номер телефона, я просто выберу функцией из строки только цифры), меня больше интересует, будет ли от этого реальная польза, или это все пережитки прошлого. Я вот например очень сильно сомневаюсь, что перенос такого поля (varchar(255) с индексом) в отдельную таблицу, где будет уже 4 индекса(pk, fk на основную таблицу, номер в int и guid) вместо одного, построенного по varchar(255), с учетом того, что в среднем это поле будет заполнено на 60% от общего числа строк. P.S. Я не говорю, что нужно поголовно лепить везде varchar'ы, но мне хотелось бы знать, стоит ли вот такие махинации переделывания большого количества зависимостей да еще и перегона старых данных туда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 11:26 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
demon1992Переделать не проблема (если быть конкретным, это поле номер телефона, я просто выберу функцией из строки только цифры), меня больше интересует, будет ли от этого реальная польза, или это все пережитки прошлого. я бы просто уменьшил ширину(размер) поля. Телефон это всё таки не число. Большие varchar поля могут негативно сыграть на сортировке. Хранятся то они всё равно в сжатом виде ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 11:35 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
demon1992, тут два момента. 1. - переделывать номер телефона с varchar на int - странная идея. Кроме того, в int хранится до 2х миллиардов, а 9хх ххх-хх-хх - это 9 миллиардов. Так что не влезет. Ну и, уже написали, что varchar и char хранятся по длине значения, а не по объявленному размеру строки. 2. насчет "много полей(300)", и прочего. Есть такое понятие как основные (первичные) данные, и дополнительные (вторичные" данные. Если телефон может быть указан, а может быть не указан, то вообще столбцы такого типа надо выносить из этой таблицы в отдельную, и связывать ее с основной 1:1. Кроме того, это зависит от запросов - насколько часто идут обращения к основной таблице, и насколько часто нужно доставать несколько номеров телефонов, или в конкретный момент достается только один номер телефона. Это т.н. "денормализация". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 11:42 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
Если предположить, что большая таблица - это таблица, например, заказов, то для меня как-то противоестественно в ней искать "Что заказал Иванов Иван Иванович за последний месяц". Не противоестественно искать по id-шнику "Иванова Иван Ивановича". ИМХО, требуется рефакторинг, возможно глубокий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 11:52 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
Симонов Денис, Об этом я тоже подумал, но почему то такое решение не устраивает. kdvпеределывать номер телефона с varchar на int - странная идея. Кроме того, в int хранится до 2х миллиардов, а 9хх ххх-хх-хх - это 9 миллиардов. bigint тогда :) Меня убеждают что индекс по варчар зло, поэтому, если кто то знает, подскажите пожалуйста: есть конкретный пример - поле varchar(255) c индексом, какой я получу профит от того, что заморочусь и перенесу это поле в отдельную таблицу, но уже с типом BIGINT, с учетом того что поле необязательное, но его заполненность сейчас больше 90%. Главный акцент мне делают на том, что все дело в индексе и нужно срочно избавляться от индексов по varchar. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 12:23 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
demon1992Меня убеждают что индекс по варчар зло кто убеждает? Поклонники PostgreSQL? У Firebird: префиксное сжатие ключей индекса, и индекс обновляется только если обновляется конкретный столбец. demon1992какой я получу профит от того профит можно оценить только на конкретной системе, и конкретных запросах SQL. Пока ничего кроме геморроя на клиенте с преобразованием всяческих форматов номера телефона в число (туда и обратно) я не вижу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 12:27 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
demon1992Главный акцент мне делают на том, что все дело в индексе до кучи. Акцент, видимо, делают на том, что поиск по индексу исключительно префиксный (или полный), а номер телефона могут искать и без префикса. В этом случае да, индекс по "номеру телефона" будет бесполезен, а число или варчар - по барабану. Кроме того - у вас префикс страны всегда +7? Если нет, то тогда придется делать еще один столбец. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 12:32 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
kdv, Спасибо за ответ. Но тут собака даже не в этом зарыта, а в том, что якобы индекс по полю varchar супер медленный по сравнению с int/bigint, а также место занимает очень много, не безопасный, не знаю как еще описать. Вот поэтому я и не могу понять, какую выгоду я получу от того, заменю индекс с varchar(255)(или даже меньше, поле вполне можно ужать) на int. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 12:34 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
demon1992, вам несут бред. Я так понимаю это байка выплыла по мотивам что использовать guid или целочисленный автоинкремент в качестве ключа. Там да, из-за того что автоинкремент генерируется последовательно такой индекс будет компактный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 12:46 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
Не ясно, зачем для номера телефона 255 символов, если максимальная длина - 12. И, конечно, они влезут в BIGINT, который 8 байт. А индекс тут бесполезен, т.к. искать в любом случае придется через LIKE, либо через доп. поле(я) (с длиной 7(10) символов). Может быть смысл в доп. таблице с тремя полями - полный, 10 знаков и 7 знаков (bigint, bigint и int). За одно это даст возможность указывать несколько номеров. А вообще всё зависит от задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 13:03 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
demon1992bigint тогда :) Телефон не может быть целым. Точка. У меня он начинается на +044. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 13:12 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
demon1992 поле номер телефона, я просто выберу функцией из строки только цифры Скобочки/дефисы, опять-таки, могут выделить из полного (десять цифр) номера код страны и населённого пункта. А в коде города может быть разное количество цифр. Не то чтобы это всё мешает переделать номер телефона в целочисленное поле, но не худо бы учитывать разные ньюансы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 13:14 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
demon1992что якобы индекс по полю varchar супер медленный по сравнению с int/bigint, а также место занимает очень много, не безопасный, не знаю как еще описать. "супер-медленный" это как? Кто там советы дает? Мы их тут видели? У них сертификаты прохождения курсов есть, это какие-то известные специалисты по Firebird? Насчет "очень много места" - выгрузите ваш столбец с телефонами куда-то. Создайте базу. Создайте таблицу с варчар и инт. Загрузите ваши данные в варчар, сконвертируйте в инт. Проиндексируйте оба столбца. Получите статистику gstat -r, сравните размеры обоих индексов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 13:17 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, пришел лесник, и всё обломил :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 13:18 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
15.10.2020 13:18, kdv пишет: > пришел лесник, и всё обломил :-) безапеляционно (и неверно) Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 13:19 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
Мимопроходящий, да, это какой-то внутренний формат. С нуля кодов нет http://ostranah.ru/_lists/phone_codes.php ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 13:24 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
kdvда, это какой-то внутренний формат. Нет, это опять вылез мой маразм. Я так долго не пользовался телефоном, что всё забыл. PS: К примерам выше с буквами и дополнительным номером могу добавить самый типичный случай: два телефона у человека. И нет, громоздить под них отдельные поля или даже отдельную таблицу - совсем неразумный вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 13:33 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov demon1992bigint тогда :) Телефон не может быть целым. Точка. У меня он начинается на +044.+ можно добавлять при отображении в интерфейсе, если длина номера 11 или 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 13:36 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
Проблему поиска и отображения номера под конкретную задачу это не то о чем я хотел узнать :) Это скорее конкретный пример, из-за чего все началось. Вся проблема в индексе, что использовать индекс по варчар плохо, и надо срочно сделать интовое поле и индексировать по нему. А собственно все что я хотел для себя прояснить, есть ли реальное подтверждение того, что индекс по тексту чем то уступает индексу по числу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 14:18 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
demon1992А собственно все что я хотел для себя прояснить, есть ли реальное подтверждение того, что индекс по тексту чем то уступает индексу по числу. Бремя доказательств на плечах утверждающего. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 14:28 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov Было время, когда код города-героя Москва начинался с(о значащего) нуля. Ещё в номере может быть 'допномер, а "удачный" номер может быть задан фразой по буквам на кнопочках. Или там могут быть всякие W из правил набора. Скобочки/дефисы, опять-таки, могут выделить из полного (десять цифр) номера код страны и населённого пункта. А в коде города может быть разное количество цифр. Не то чтобы это всё мешает переделать номер телефона в целочисленное поле, но не худо бы учитывать разные ньюансы. Большая часть из этого - задача визуализации, а вот возможность добавочного номера да, стоит предусмотреть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 14:28 |
|
||
|
VARCHAR VS INT
|
|||
|---|---|---|---|
|
#18+
Во времена далёкие, теперь почти былинные, телефонные номера, во всяком случае в Ленинграде, начинались с буквы. На пальцекрутном диске они, ессно, тоже присутствовали. Обозначали эти буквы районные АТС. Были в народе даже присказки, типа - опять ты всё сделал через Некрасовскую АТС. Бо она буквой Ж обозначалась. Я это к чему. Не исключаю, что нечто в этом роде может всплыть. С целью затруднить заграничным шипиёнам звонки нашим гражданам или просто бюджет попилить на внедрение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 14:35 |
|
||
|
|
start [/forum/topic.php?fid=40&fpage=11&tid=1560226]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
46ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
| others: | 12ms |
| total: | 174ms |
| 0 / 0 |
