Существует ли способ произвести пользовательские типы данных в MySQL?
У меня есть база данных, которая хранит (среди прочего), следующие сведения:
- Аппаратные идентификаторы
BIGINTs - Емкости хранения
BIGINTs - Аппаратные названия
VARCHARs - Всемирные имена порта
VARCHARs
Я хотел бы смочь получить более усовершенствованное определение этих типов данных. Например, аппаратные идентификаторы не имеют никакого числового значения, таким образом, я не забочусь, как они отформатированы при отображении. Емкости хранения, однако, являются кардинальными числами и в запросе пользователя, я хотел бы подарить им тысячи и десятичные разделители, например, 123,456.789. Таким образом я хотел бы совершенствовать BIGINT в, сказать ID_NUMBER и CARDINAL.
То же с Аппаратными Названиями, которые являются простым текстом и WWPNs, которые являются hexstrings, например, 24:68:AC:E0. Таким образом я хотел бы совершенствовать VARCHAR в ENGLISH_WORD и HEXSTRING.
Определенные типы данных, которые я составил, только в иллюстративных целях.
Я хотел бы хранить всю эту информацию в одном месте, и я задаюсь вопросом, знает ли кто-либо о хорошем способе содержать это все в моих определениях таблицы MySQL. Я мог использовать поле Comment определения таблицы, но это пахнет подозрительным мне.
Один подход должен был бы определить структуру данных в другом месте и использовать то определение для генерации моего CREATE TABLEs, но это было бы майором, переделывают кода, который я в настоящее время имею, таким образом, я ищу альтернативы.
Какие-либо предложения? Используемый язык приложения является Perl, если это помогает.
2 ответа
Хороший способ сделать это - использовать представления. Например, чтобы вставить запятые в число, вы можете использовать:
mysql> create table foo (id int);
Query OK, 0 rows affected (0.12 sec)
mysql> insert into foo (id) values ( 123456789);
Query OK, 1 row affected (0.00 sec)
mysql> create view v_foo as select format(id, 0) as id from foo;
Query OK, 0 rows affected (0.10 sec)
mysql> select * from v_foo;
+---------------+
| id |
+---------------+
| 123,456,789 |
+---------------+
1 row in set (0.02 sec)
Вы можете использовать другие строковые функции для форматирования других полей и сохранения их в определении представления.
Я предложу ответ, который ставит вопрос.
Одной из мантр, которую любят напевать люди, моделирующие базы данных, является разделение презентационного слоя (форматирования) и данных, и я полагаю, что соответствующая часть из like звучит примерно так:
"Ты не должен хранить форматированные данные в своих базах данных, и ты не должен дискриминировать любой выбор форматирования. Вы должны хранить данные в собственных поддерживаемых типах данных. Ваши приложения должны обеспечивать уровень представления и форматировать ваши колонки."
Ну, ответ friedo не противоречит этому напрямую - данные представляются только через представление, хранение данных остается родным.
Тем не менее, это зависит от того, как вы определяете презентационный слой - если представление и настройки сервера считаются частью презентационного слоя, то все в порядке, в противном случае возможны проблемы, поскольку я, возможный пользователь вашей системы, не смогу указать, что мой разделитель тысяч - одинарная кавычка (а это так, по крайней мере, в месте моего нынешнего проживания).
Кроме того, если вы пойдете по этому пути, как вы думаете, сколько времени пройдет до того момента, когда вам придется иметь дело с запросами на обратную обработку данных из текста в число и, возможно, попадать в ситуации, когда это может быть неоднозначно (например, DD/MM/YY против MM/DD/YY)?
Вышеприведенная тирада относится только к форматированию, определение количества десятичных цифр определяет область ваших данных и является хорошей вещью, поскольку это ограничивает возможность попадания в вашу базу данных противоречивых данных.
EDIT: (развлекаясь с пуристской точкой зрения немного дальше, относительно оснований чисел) Утверждение, что шестнадцатеричные числовые данные не имеют смысла в других базах, в целом неверно. Числовые значения не имеют основания и могут быть представлены в любом основании. Их область (набор допустимых значений) одинакова.
Выбор шестнадцатеричного формата для MAC-адреса является естественным в силу исторических причин и того факта, что, например, в этом формате легко прочитать часть производителя. Выбор "смешного" формата для адресов IPv4 является исторической и, возможно, анекдотической причиной.
Но и то, и другое - лишь выбор, и внутри хорошая система будет хранить их без предубеждений (например, хранить IPv4 в виде текста - не очень хорошо). Когда РСУБД представляет вам результаты запроса (на экране), она уже берет на себя роль приложения и определенным образом форматирует результаты.
Это не существенно, и формат, который вы будете использовать в своем приложении, не должен влиять на то, как вы храните Storage Capacities или другие свойства сущности.
Итак, я говорю, что это данные конфигурации приложения (метаданные к основной дате) и, конечно, они могут/должны храниться в базе данных, но в MySQL (который не так богат на определение пользовательских типов) они не могут вписаться в определение таблицы и должны просто храниться в другой таблице, которую приложение будет читать и применять к вашим столбцам при представлении данных пользователю, а не каким-то хакерским способом, который не будет переносимым.
Например, идея с представлением работает, но можете ли вы легко запросить представление, чтобы получить форматы, которые применяются к полям? Или, допустим, вы хотите изменить форматирование во всех вхождениях поля WWPN во всех запросах, которые его используют (hexstring также звучит как уже неправильный), это будет легко? Или если есть другие запросы, которые преобразуют данные и записывают их в другую таблицу, вы будете записывать их с примененным форматом или без него (перепарсинг)? И т.д.
Теперь, если у вас есть таблица, в которой хранятся данные конфигурации приложения, такие как FieldFormatting: Table, Field, Format, CheckRules, LongFormat (или то, что имеет наибольший смысл в вашей ситуации) тогда вышеуказанные вопросы становятся немного проще, и вы получаете возможность выбирать дополнительные опции для вашего приложения и бизнес-логики.
Если вам действительно (очень, очень) необходимо обеспечить прямой доступ к базе данных, а родные типы сделают данные нечитаемыми для пользователей, и вы просто должны предварительно отформатировать их, то вы даже можете использовать приведенную выше таблицу для полуавтоматической генерации и обновления представлений/запросов.
ПРИМЕЧАНИЕ: Я придерживаюсь здесь пуристской точки зрения, поскольку у меня есть ощущение, что вы принимаете здесь проектные решения, а не гонитесь за последней каплей производительности или удобства (например, между типами данных приложения и типами данных базы данных), когда практические вопросы могут быть более важными, чем рекомендации и правила моделирования. Но вопросы из последнего абзаца остаются в силе.