Вопрос о типах данных SQL

Добрый день.
Создавая структуру БД, задумался над такой вещью как типы полей в SQL таблицах. По логике если я с помощью PHP произвожу и запись данных в базу и считывание данных из неё с последующей обработкой(математические операции или же приведение к любому типу данных или просто вывод данных), то получается что для большинства полей(кроме id например) я могу использовать тип данных VARCHAR и просто менять длину для этих полей в зависимости от предполагаемых данных?
Я так понимаю что если мы с помощью самого SQL производим математические операции или строковые или другие работы с типами данных, тогда это важно, но тогда возникает вопрос: "Как лучше производить те же самые математические операции, средствами PHP или SQL?"

P.S. Сильно не пинайте если мои слова взрывают кому то мозг и кажутся бестолковыми, просто хочу понять как правильно мыслить при создании структуры БД.

типы данных в бд влияют на многое, во-первых это выборка, по некоторым типам проще сканить таблицу чем по другому, индексы работают лучше, во-вторых математические и строковые операции работают по разному, в третьих это только мускуль пренебрегает типами, в постгресе например такое не прокатит

-----
Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.

т.е. Я так понимаю лучшая практика это всё же строгая типизация данных?

Правильно мыслишь! Если правильно выставляешь типы, выигрываешь в скорости обращения к db, быстрее выборка данных, и объемы крупных db меньше! Поле integer с тем же католичеством символов меньше чем string а поле string меньше чем varchar! Из этого следует то что смешанные данные обрабатываются дольше чем в чистом виде!И не когда не указывай больше символов чем планируешь хранить, ведь все пустые символы даже если ты не указал их они забиваются нулями в структуре db!

0) что такое тип string в СУБД? Какой-то диалект?
1) за счёт чего занимает меньший объём памяти?


Так себя ведёт char и, обычно, индексные записи.
varchar и text хранят отдельно длину строки и паддинга при хранении не требуют.


Правильная практика - когда дизайн базы исключает добавление ошибочных данных.
Правильный тип данных, а так же ограничения уникальности, внешних ключей, check (глупый mysql последнее не умеет) - это банально удобно. Когда ошибка сваливается в одном месте непосредственно при записи неправильных данных - вы знаете, что что-то сломалось именно там, где вывалилась ошибка и сама база не пострадала. В отличии от ситуации, когда вы прочитали данные из БД, а там 'hello world' вместо суммы денег на балансе пользователя.
Затем правильные типы позволяют внятно использовать функционал СУБД - это всё-таки система управления данными, и функционала обработки у них достаточно, даже у mysql. Банально фильтр по числу между 100 и 200 - строковой тип просто это сделать не даст. А не просто - будет медленно.
И да, база занимает существенно поменьше данных на диске и в памяти.

-----
PostgreSQL DBA

Большое спасибо за советы. Может какую литературу посоветуете на русском и желательно из свежих по sql в целом? Конечно можно просто рыться в интернете и читать ото всюду по чуть чуть, но больше понимаю когда мысль заложенная в книге пытается донести саму суть и потенциал изучаемого процесса.
P.S. Уровень знания SQL у меня самый базовый(или и того меньше), знаю самый элементарные команды и типы данных по этому хотелось бы почитать литературу которая будет доступно доносить информацию. Сейчас вроде бы начал читать книгу "SQL. Полное руководство 3е издание 2015г." Надеюсь что зайдёт...

(Отредактировано автором: 26 Марта, 2017 - 22:48:15)

0) Извиняюсь то что не правильно написал, хотел написать char тип

Величина CHAR(4) Требуемая память VARCHAR(4) Требуемая память
'' ' ' 4 байта '' 1 байт
'ab ' 'ab ' 4 байта 'ab' 3 байта
'abcd' 'abcd' 4 байта 'abcd' 5 байтов
'abcdefgh' 'abcd' 4 байта 'abcd' 5 байтов

1) То что разные типы данных занимаю разный объем количество байт!

а вот тебе цитата из мануала!

Если длина значений, сохраняемых в столбце меняется незначительно, предпочтительнее использовать char, т.к. таблицы со строками фиксированной длины обрабатываются эффективнее, чем с переменной.

(Отредактировано автором: 26 Марта, 2017 - 23:32:51)

Если под 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" - то это введение в заблуждение, т.к. зависит от реального распределения данных.


А где сказано, что речь о mysql?
Например, тоже вполне мануал: https://www[dot]postgresql[dot]org/docs/[dot][dot][dot]e-character[dot]html

-----
PostgreSQL DBA

dbaguru[dot]ru
(Добавление)
А так в обще себя приучил к строгой типизацией с java, ибо много граблей выходит с этими типами а приведение в другой вид это лишний код и лишняя память.

Где сказано в этой теме, что эта тема про mysql?

Да и если говорить именно про mysql - тоже сюрпризы бывают.
https://dev[dot]mysql[dot]com/doc/refman[dot][dot][dot]5[dot]7/en/char[dot]html

Хоп - и char становится строкой переменной длины.
В mysql вообще много сюрпризов.

-----
PostgreSQL DBA

На 99.9% то что автор этой темы имел в виду именно mysql
(Добавление)
А так извини за невнимательность!

Ну на самом деле я работаю сейчас именно с MySQL, но в вопросе я имел ввиду SQL в целом.