Текстовые данные в SQL

Рет қаралды 6,942

8 жыл бұрын

Как записывать текстовые данные в базе данных, говорящей на языке SQL.
В этом видео я стараюсь не говорить о какой‐то конкретной базе данных, но привожу некоторые конкретные примеры.

Пікірлер: 16

@Didar.Kussain 2 жыл бұрын

👍

@AnySoftUser 8 жыл бұрын

побольше бы таких познавательных видео по бд и sql, особенно по нормализации и построении бд на стадии проекта...

@AlexBekhtin 8 жыл бұрын

VarChar не от слова Variable, а от varying. Только про text/blob можно записать несколько уроков. В каждой СУБД свои тонкости и названия для них. Да и вообще на практике с char/varchar тоже всё немного не так, как в уроке: char и varchar на диске храниться могут одинаково, а в памяти нет, причём для обработки в процедурах и сортировке будут занимать максимальный размер и т.д.

@user-iu6yz6ck6h 8 жыл бұрын

Супер. Спасибо большое.

@maxiv3034 8 жыл бұрын

о, да. это было очень во время и полезно.

@vonseven 4 жыл бұрын

спасибо за ваш труд

@user-iv7wq2tp6o 3 жыл бұрын

Это круто )

@dutnum5766 7 жыл бұрын

Не понятно вот что. Ведь использование любых полей переменной длины ведет к серьезным последствиям: если в таблице есть хоть один VARCHAR, то вся длина (в байтах) записи становится переменной и теряется возможность быстрого доступа к записи по индексу (по сути вместо массива мы получаем односвязанный список). Для быстрого доступа придётся видимо строить индекс (а если бы был CHAR то индекс не нужен). А что происходит при модификации записи с VARCHAR? Допустим мы добавили 1 символ в VARCHAR - придётся "раздвигать" данные во всём файле чтобы освободить место для этого символа (т.е. перезаписывать весь хвост файла). Ну или может модифицируемую запись пометить удалённой и перезаписать в конец изменённой. В любом случае всё это гораздо дороже чем в случае CHAR - достаточно перезаписать один единственный символ в файле. Получается что нужно стремиться к тому чтобы полей переменной длины в таблицах не было без крайней необходимости.

@alvaro3941 5 жыл бұрын

Что делать если случайно sql файл переделал в блокнот, как все вернуть обратно

@alexlee395 2 жыл бұрын

А json?

@ROBITON-ht2jb 6 жыл бұрын

Я совсем не понял, почему для записи номера телефона ""нужно всегда использовать текстовый тип данных". Объясните, пожалуйста, почему. явижу только доводы против этого

@VladimirMozhenkov 6 жыл бұрын

Ну для начала есть номера, которые вы просто не сможете вводить. Например многие британские номера начинаются с цифры ноль. В некоторых случаях встречал что-то с "00". Как вы такое введёте в цифровое поле? В США принято писать многие номера буквами (теми, которые используют для СМС). Как вы такие введёте? Будете их в цифры переводить обратно? Что делать с номерами, где присутствует расшерение? Такие очень часто в некоторых странах встречаются, к примеру: 12345343434#123. Как вы это вобьёте? Но всё это неважно, ведь может быть вы знаете, что будут только те, что начинаются с 1-9 и состоят только из 0-9. Суть в том, что стоит использовать тот тип, который подходит под использование. Спросите у себя: Собираюсь-ли я находить сумму двух номеров телефона, будет-ли мне нужно найти средне-статистический номер... вообще хоть один раз мне понадобятся математические операции? И потом задайте себе вопрос: Есть-ли причина найти первые 3 знака номера телефона (а ведь это не цифровая, а текстовая операция)? Мне интересно где вы нашли доводы против этого. Я никогда такого не слышал, можете ссылку дать?

@404Negative 4 ай бұрын

@@VladimirMozhenkov первые 3 знака номера телефона можно было бы найти через интежер дивижн