Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737 Форумы портала PHP.SU :: Вопрос о типах данных SQL
Покинул форум
Сообщений всего: 49
Дата рег-ции: Дек. 2016
Помог: 0 раз(а)
Добрый день.
Создавая структуру БД, задумался над такой вещью как типы полей в SQL таблицах. По логике если я с помощью PHP произвожу и запись данных в базу и считывание данных из неё с последующей обработкой(математические операции или же приведение к любому типу данных или просто вывод данных), то получается что для большинства полей(кроме id например) я могу использовать тип данных VARCHAR и просто менять длину для этих полей в зависимости от предполагаемых данных?
Я так понимаю что если мы с помощью самого SQL производим математические операции или строковые или другие работы с типами данных, тогда это важно, но тогда возникает вопрос: "Как лучше производить те же самые математические операции, средствами PHP или SQL?"
P.S. Сильно не пинайте если мои слова взрывают кому то мозг и кажутся бестолковыми, просто хочу понять как правильно мыслить при создании структуры БД.
OrmaJever
Отправлено: 25 Марта, 2017 - 21:45:30
Активный участник
Покинул форум
Сообщений всего: 7540
Дата рег-ции: Янв. 2010 Откуда: Чернигов
Помог: 299 раз(а)
типы данных в бд влияют на многое, во-первых это выборка, по некоторым типам проще сканить таблицу чем по другому, индексы работают лучше, во-вторых математические и строковые операции работают по разному, в третьих это только мускуль пренебрегает типами, в постгресе например такое не прокатит
----- Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.
ЧИМ
Отправлено: 26 Марта, 2017 - 18:16:53
Новичок
Покинул форум
Сообщений всего: 49
Дата рег-ции: Дек. 2016
Помог: 0 раз(а)
OrmaJever пишет:
типы данных в бд влияют на многое, во-первых это выборка, по некоторым типам проще сканить таблицу чем по другому, индексы работают лучше, во-вторых математические и строковые операции работают по разному, в третьих это только мускуль пренебрегает типами, в постгресе например такое не прокатит
т.е. Я так понимаю лучшая практика это всё же строгая типизация данных?
quad
Отправлено: 26 Марта, 2017 - 19:21:44
Новичок
Покинул форум
Сообщений всего: 39
Дата рег-ции: Март 2017 Откуда: Россия
Помог: 0 раз(а)
Правильно мыслишь! Если правильно выставляешь типы, выигрываешь в скорости обращения к db, быстрее выборка данных, и объемы крупных db меньше! Поле integer с тем же католичеством символов меньше чем string а поле string меньше чем varchar! Из этого следует то что смешанные данные обрабатываются дольше чем в чистом виде!И не когда не указывай больше символов чем планируешь хранить, ведь все пустые символы даже если ты не указал их они забиваются нулями в структуре db!
Мелкий
Отправлено: 26 Марта, 2017 - 20:09:34
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
quad пишет:
поле string меньше чем varchar
0) что такое тип string в СУБД? Какой-то диалект?
1) за счёт чего занимает меньший объём памяти?
quad пишет:
ведь все пустые символы даже если ты не указал их они забиваются нулями в структуре db!
Так себя ведёт char и, обычно, индексные записи.
varchar и text хранят отдельно длину строки и паддинга при хранении не требуют.
ЧИМ пишет:
лучшая практика это всё же строгая типизация данных?
Правильная практика - когда дизайн базы исключает добавление ошибочных данных.
Правильный тип данных, а так же ограничения уникальности, внешних ключей, check (глупый mysql последнее не умеет) - это банально удобно. Когда ошибка сваливается в одном месте непосредственно при записи неправильных данных - вы знаете, что что-то сломалось именно там, где вывалилась ошибка и сама база не пострадала. В отличии от ситуации, когда вы прочитали данные из БД, а там 'hello world' вместо суммы денег на балансе пользователя.
Затем правильные типы позволяют внятно использовать функционал СУБД - это всё-таки система управления данными, и функционала обработки у них достаточно, даже у mysql. Банально фильтр по числу между 100 и 200 - строковой тип просто это сделать не даст. А не просто - будет медленно.
И да, база занимает существенно поменьше данных на диске и в памяти.
----- PostgreSQL DBA
ЧИМ
Отправлено: 26 Марта, 2017 - 22:16:56
Новичок
Покинул форум
Сообщений всего: 49
Дата рег-ции: Дек. 2016
Помог: 0 раз(а)
Большое спасибо за советы. Может какую литературу посоветуете на русском и желательно из свежих по sql в целом? Конечно можно просто рыться в интернете и читать ото всюду по чуть чуть, но больше понимаю когда мысль заложенная в книге пытается донести саму суть и потенциал изучаемого процесса.
P.S. Уровень знания SQL у меня самый базовый(или и того меньше), знаю самый элементарные команды и типы данных по этому хотелось бы почитать литературу которая будет доступно доносить информацию. Сейчас вроде бы начал читать книгу "SQL. Полное руководство 3е издание 2015г." Надеюсь что зайдёт...
1) То что разные типы данных занимаю разный объем количество байт!
а вот тебе цитата из мануала!
Если длина значений, сохраняемых в столбце меняется незначительно, предпочтительнее использовать char, т.к. таблицы со строками фиксированной длины обрабатываются эффективнее, чем с переменной.
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
quad пишет:
1) То что разные типы данных занимаю разный объем количество байт!
Если под string подразумевать char - тогда да, один или два байта на хранение длины строки в varchar разницы будет.
А как начинаем хранить данные? За допустимый максимум значения примем 65000. Ну и для порядка ограничимся mysql.
числовые типы - 2 байта хватит
char - от 5 до 20 байт (есть мысли, почему я называю диапазон с четырёхкратной разницей? Это далеко не случайно. Длина значения char в байтах будет фиксированной, а вот какой именно - зависит от другого параметра)
varchar - от 2 до 21 байт (технически от 1 до 21, но допустим что по задаче пустая строка исключена)
Например, "385" сохраним.
unsigned smallint 2 байта
char - от 5 до 20 байт
varchar - от 4 до 13 байт
Числовой конечно вне конкуренции, зато ой, varchar оказался компактнее.char'а.
Веселее если говорить про поле с email - по rfc допустимо до 254 байт. Мой адрес почты занимает 12 байт, как то жалко будет под него выделять от 254 до 1016 байт. А в varchar'е всего от 13 до 50 байт.
Поэтому если цитату читать как "поле char меньше чем varchar" - то это введение в заблуждение, т.к. зависит от реального распределения данных.
quad пишет:
Если длина значений, сохраняемых в столбце меняется незначительно, предпочтительнее использовать char, т.к. таблицы со строками фиксированной длины обрабатываются эффективнее, чем с переменной.
in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.
----- PostgreSQL DBA
quad
Отправлено: 27 Марта, 2017 - 19:54:40
Новичок
Покинул форум
Сообщений всего: 39
Дата рег-ции: Март 2017 Откуда: Россия
in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.
dbaguru[dot]ru (Добавление)
А так в обще себя приучил к строгой типизацией с java, ибо много граблей выходит с этими типами а приведение в другой вид это лишний код и лишняя память.
Мелкий
Отправлено: 27 Марта, 2017 - 21:29:03
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.