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

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

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

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

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

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


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


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

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

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, т.к. таблицы со строками фиксированной длины обрабатываются эффективнее, чем с переменной.

Если под 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

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 вообще много сюрпризов.

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

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