Задача вроде бы очень простая. Есть некоторое количество таблиц каждая со своей структурой среди которых таблица с именем, например image и полями для краткости изложения: id int auto_increment, filename varchar(255). Задача снабдить ряд таблиц ссылкой на изображение решается тривиально через добавление поля image_id. Сделали запрос - получили по указателю имя файла.

Но как-то все не сшивается если захотеть получать изображения. Сначала все тоже вроде просто. Выкидываем из таблиц поле image_id, заводим таблицу image_list куда оно и переезжает в паре с указателем на родителя: (int id auto_increment, int parent_id, int image_id). Теперь можно связать с любой таблицей любое количество изображений.

Но проблема в том, что parent_id в БД состоящей из более чем 1 таблицы не уникален. Дубовые решения как то 1) специфически размножать таблицу image_list для каждой нуждающейся в изображениях таблицы; 2) завести некий глобальный ID типа UUID; 3) завести процедуру генерации глобального ID - грозят геморроем в будущем.

Легко приходит на ум программистское решение передать в запрос имя таблицы, типа добавить this . Но тогда придется либо сохранять в каждой записи имя родительской таблицы, либо заводить еще таблицу с парочкой ID - имя таблицы. В information_schema я ничего подходящего в таблице TABLES не нашел.

Может быть не там искал или вообще все не так делается?

При установлении связи сверху-вниз можно получить ровно 1 штуку. При установлении снизу-вверх - любое количество штук.

Я понимаю что ID таблицы в сущности ее имя. Но как-то неправильно хранить кучу юникодовых байтов в каждой записи моста отчего и пришла такая идея заменить эту кучу четырьмя int unsigned.

В парадигме программирования эта задача решается в один счет введением смещения адреса. Однако творцы SQL заповедали никаких адресов и смещений не юзать. Отсюда подозрение что задача изначально сформулирована неправильно коли требует смещения в форме имени таблицы к указателю.

tanglirЯ не понял, разве вариант с image_id в каждой таблице не позволяет "связать с любой таблицей любое количество изображений"? Или имелось в виду "связать с каждой записью любое количество изображений"?

Не позволяет. Количество связанных с таблицей изображений будет в точности равно количеству записей в ней, а не любому количеству, даже если там вообще ни одного изображения не связано (ну, то есть image_id is NULL). Следовательно формулировка связать с каждой записью любое количество изображений - тавтология.

tanglirВыражайтесь яснее, пожалуйста.

Читайте внимательнее и вообще подразумевается что жевать не придется.

Меня интересует либо способ идентифицировать таблицу не используя ее имя (и прочие длинные варианты), либо какой-то принципиально иной способ который не потребует использовать ее имя (и прочие длинные варианты).

Снизу-сверху положения относительные. Мост на самом деле получается посредине. Слева у него куча не уникальных parent_id (по логике отношений), справа куча не уникальных image_id. То есть реализуется модель многие ко многим.

Все было бы шиколадно если бы parent_id однозначно указывал на id реципиента.

Arhat109Связи типа "М:М" требуются тогда (и только тогда!) когда требуется одну и туже запись о картинке сопоставить с несколькими заданными строками в других таблицах... ну типа, нам дорого плодить несколько одинаковых названий файла с картинкой... так бывает тоже. Решается, как всем известно, опять же легко добавлением доп. таблицы связи... но вот тут, возможны варианты, ибо или их надо плодить к каждой базовой сущности, или переходить на гуйид, или делать динамический скуль... чего многие СУБД - очень не любют...

Так и записано в первом сообщении, только несколько иным языком.

За исключением отрезанной части. Откуда 1:М если совершенно ясно что будет 1:1. Примеры что ли придумывать?

create table prod (
id int auto_ blah-blah,
name varchar(50),
image varchar(255)
);

create table pubs (
id int auto_ blah-blah,
content text,
image varchar(255)
);

create table menu (
id int auto_ blah-blah,
name varchar(50),
image varchar(255)
);

create table ad (
id int auto_ blah-blah,
url varchar(50),
image varchar(255)
);

Ну и так далее


М очевидно не фигурирует.

Имена файлов вообще не при чем. Изображение характеризуется несколькими параметрами которые в данном случае продукту (а равно публикации, модели, коллекции, альбому и тп) в упор не стучат. Другими словами даже если нужна была 1 картинка, под картинки все равно была бы заведена своя таблица. А в данном конкретном случае имя файла вообще не существует, но сохраняется для имитации человеческого отношения в интерфейсе.

Пришлось-таки жевать.

Arhat109javajdbc,

в первом посту было: "Но как-то все не сшивается если захотеть получать изображения."

ответ: чтобы получить изображение

Как там выше замечено, чукча не читатель. Написано же - изображения, а не изображение. С одним никаких проблем, со многим ко многим единственная в том, что у многих может совпасть id. Самый коротки путь ввести смещение говоря языком программирования, или дополнительный критерий отбора языком запросов. Это опять же элементарно если сохранять вместе с отче_йди фамилию его семьи (имя таблицы). Я счел это расточительным и хотел узнать можно ли где-то отыскать нечто типа ID из четырех байтов.

Ну и вторая часть - может быть вообще все делается иначе, а я отстал от прогресса.

Однако пока что ни то ни другое не прояснилось ни на бит.

Arhat109, но потом "внезапно" переходит на связи картинок с разными сущностями "теперь .. с любой таблицей..." -- этот пассаж - откуда?!Ё

В этом и весь цукерберг. Все таблицы разношерстные и все хотят быть связанными с произвольным числом изображений. Например менегер заводит номенклатуру и связывает несколько картинок с ней. Журналист пишет статью и связывает с ней несколько картинок и того же самого источника. Дизайнер делает витрину и связывает с ней несколько картинок из того же самого источника. У каждого своя таблица, но таблица изображений со всей спецификой - одна на всех. Чтобы залинковать в 1 запись больше чем 1 изображение требуется диспетчерская. Но диспетчер оказывается в неоднозначном положении на своем стуле, поскольку у каждого из вышеперечисленных пересекающийся набор идентификаторов. Епрст, вроде бы тривиально, а уже столько постов.