Rule of thumb

[metaclass]

Если в стандарте, документации или технологии упоминаются гуиды или в структурах присутствуют поля вида object_id, class_id, instance_id - с 99% вероятностью это будет дичайше непригодное к использованию ИТ-шайзе, придуманное людьми, которые не умеют делать нормальные API (или, что почти эквивалентно - не понимают, что такое системы типов) и вместо того чтобы подумать - делают "универсальное решение".

Comments

[aamonster.livejournal.com]

Э... А как же всякая хрень в базах данных? Или имеется в виду, что все эти id живут под капотом и наружу не выпускаются, прячась при необходимости за непрозрачными обёртками?

[metaclass.livejournal.com]

В базах данных такое бывает, если делать EAV. Это иногда допустимо, когда надо хранить неприятные данные (графы из сложных объектов с кучей атрибутов, для CAD и прочего такого).

В других случаях лучше все именовать явно, кроме автоматически генерируемых идентификаторов объектов - те желательно числовыми, а гуиды - если очень хочется распределенные БД делать.


Я скорее про всякие кишки, вот как здесь: http://lwn.net/Articles/391230/

[aamonster.livejournal.com]

У меня неприятные воспоминания связаны с автоматически генерируемыми числовыми id (баг, когда они внезапно начали реюзаться после восстановления/чистки битой базы).

Но я с базами, вообще говоря, крайне мало дела имел. До такой степени, что не так давно реляционная алгебра (когда основная сущность - не строка таблицы, а множество) стала для меня откровением (я застрял в эпохе dBase II, где, насколько я помню, кроме таблиц и индексов практически ничего и не было - для задач уровня "показать Master-Detail" этого хватало).

Ну и да - я говорил именно про автоматически генерируемые id. Довольно нелепо спрашивать у клиента id, не выдав его предварительно.

[metaclass.livejournal.com]

Как раз для случая "id генерится клиентом" - гуид вполне себе решение.

в целом, тут идея такая: не использовать гуиды для вещей, у которых есть имена, а использовать их только для автогенерации уникальных идентификаторов.

[aamonster.livejournal.com]

В такой-то формулировке кажется более-менее естественным и очевидным.

Хотя, если подумать - видится исключение: создание однородной структуры для well-known и user-generated хрени (ну там, у объекта есть цвет, форма и размер, а юзер может прихреначить ещё 100500 параметров). Это, как я понимаю, тот самый случай EAV.

[tzirechnoy.livejournal.com]

И как по-вашэму, у людей есть имена?

[falcrum.livejournal.com]

У некотрых ещё и отчество, и фамилия. Топикстартер предлагает это и хранить ключом, я так понимаю. Ну, там, ещё номер соцстрахования для уникальности дописать. А потом удивляться, чего это база пухнет и дохнет от таких индексных полей.

[sbj-ss.livejournal.com]

Можно ещё задаться вопросом "а откуда должен браться номер соцстрахования?"
И будет известная история про деньги и тумбочку.

[w00dy.livejournal.com]

особенно забавно когда люди по религиозным причинам этот самый уникальный номер соцстрахования могут не иметь :)

[juan-gandhi.livejournal.com]

Ой. Имена людей - это пиздец проблема.

[sbj-ss.livejournal.com]

Это очень удобно в проекте одного человека, да и то если проект десять лет не мучить, периодически возвращаясь. А если взять тот же WMI по ссылке, то стопицот вендоров замаются искать свободные имена, потом будут "^^^### ACPI_0RK_88_YPOBH9| ###^^^".