Хранение типизированных данных в базе данных

Question

[olegmar]

Здравствуйте, может быть заголовок плохо понятен, но я не знал, как лучше обозначить суть моего вопроса. А она вот в чём. Достаточно часто в базе данных приходится хранить данные, у которых есть принадлежность к определенному типу. Ну, например, статья может быть как новостью, так и заметкой в блоге. В таком случае в базе данных мы создаём поле, отвечающее за тип объекта. Так вот есть ли смысл каждому типу присваивать id и вставлять в базу не слово «blog», а соответствующую ему «1». Очевидно, что словом понятнее и удобнее, но что будет выгоднее, если записей — миллионы?

Answer 1

[Андрей Буров]

Есть тип ENUM

Comments

[Макс]

ENUM — достаточно порочная практика. Там, как минимум, есть грабли со вставкой значения не из списка

[Андрей Буров]

Никаких проблем нет, если использовать режим STRICT_ALL_TABLES

SET @@session.sql_mode=STRICT_ALL_TABLES;

[Aleks_ja]

И как-то странно он сортируется. Этот ENUM.

[Андрей Буров]

Ничего странного, в документации об этом всё написано

ENUM values are sorted according to the order in which the enumeration members were listed in the column specification. (In other words, ENUM values are sorted according to their index numbers.) For example, 'a' sorts before 'b' for ENUM('a', 'b'), but 'b' sorts before 'a' for ENUM('b', 'a').

Answer 2

[Макс]

Число индексируется лучше, для понимания нужно указывать комментарии к столбцам и к таблице, а в коде определять читабельные константы для таких полей

Comments

[Optik]

Или сделать таблицу-справочник значений.

[DenKrep]

А можно поподробнее про лучшую индексацию чисел? В чём проявляется лучшая индексация и откуда информация? Это только в mysql? Разве СУБД при построении b-tree не интерпретирует что число что строку просто как набор байт? (не говорим про диапазонные предикаты, учитывая специфику задачи автора вопроса).

[Артём Каретников]

А ресурсы на преобразование — тратятся или нет, как полагаете? Лучше всего это заметно как раз тогда, когда создается индекс на миллионы записей — разница будет и очень ощутимая.

[DenKrep]

Преобразование чего во что? Зачем преобразовывать? Просто Вы оперируете логическими единицами: строками / числами. С точки зрения СУБД и то и другое — набор байт. Преобразовывать их не обязательно. Либо, скажите о каких преобразованиях вы говорите. Или вы думаете, что «1» будет преобразовываться в 1? Так не будет.
Для простоты понимания, сравните кол-во места занимаемого «А» (VarChar2) и 1 (number). Может в своём примере я усложнил используя «1» и 1.

Answer 3

[mgyk]

Нет особого смысла в такой оптимизации. Повлияет только на размер занимаемый файлами на диске, на размер индекса не повлияет.
Если в этой же таблице есть текстовые поля то разница будет совершенно незаметна.

Answer 4

[merlin-vrn]

Т.е. вы хотите оптимизировать колонку «тип записи», которая занимает несколько байт (и там может фактически храниться int, если колонка enum), а при этом соседняя колонка — типа text с переменной длиной порядка нескольких килобайт? Ну, да, если повезёт, какие-то доли процента вы выиграете.

Answer 5

[DenKrep]

Честно говоря не знаю как оно внутри MySQL-а реализовано, но в Оракле такая ситуация, что integer далеко не один байт (и может доходить до 9, насколько я помню, правда и поддерживаемая разрядность у оракла тоже впечатляет).

В качестве примера на подумать:

CREATE TABLE TEST (ID INTEGER, vc VARCHAR2(10 CHAR)); INSERT INTO TEST VALUES (1,'1'); SELECT DUMP(ID), DUMP(vc) FROM TEST;

DUMP(ID) DUMP(VC)
1 Typ=2 Len=2: 193,2 Typ=1 Len=1: 49

Обращаю внимание на длины.
А индексируются короткие строки на уникальные вхождения, как правило, не хуже, не соглашусь. Другое дело если планируете использовать диапазонные предикаты… Вот тут могут возникнуть «моменты», но, думаю, тогда бы Вы не спрашивали Ваш вопрос.

Конечно, всё вышесказанное в первую очередь применим к Ораклу, но думаю что направление мысли «на проверить» понятно, а доверять, всё-равно никому нельзя :)

Answer 6

[Артём Каретников]

Давайте просто вместе подумаем. Во-первых, не обязательно использовать полный инт — сколь там типов статей у вас? TinyInt USIGNED — не перекроет? Во-вторых, если строка у вас варчарная — какой длины? Если четыре символа — можно и не заметить. А выше — имнсхо, надо использовать число.
Предполагаю с высокой вероятностью еще и то, что вам нужна будет выборка — и не только по этому полю, скорее, индекс по нескольким. Здесь еще и размер его будет важен.

Answer 7

[zapimir]

Очевидно, что словом понятнее и удобнее, но что будет выгоднее

Исходить нужно из того, что не человек же будет выбирать записи из таблицы. Поэтому лучше использовать тип данных поменьше и поудобнее для машины, а не человека. Я предпочитаю TINYINT USIGNED для всяких типов, это будет самый быстрый вариант, но если хочется наглядности можно и ENUM. VARCHAR лучше не использовать, так как чтобы его прочитать нужно сначала узнать его длину, потом уже читать, это не считая того, что сравнение чисел быстрее, сравнения строк, да и места VARCHAR будет больше занимать, как в самой таблице, так и индексе.