Существуют ли веские причины идти против архетипов базы данных «один к одному», «один ко многим» и «многие ко многим»? - PullRequest
1 голос
/ 08 марта 2019

У меня есть таблица с именем 'product' со следующими столбцами: id, имя, цена и имя таблицы.

У меня есть группа таблиц, названная в честь столбца tablename таблицы 'product' и со следующими столбцами: customer_id и количество.

Я хотел объединить таблицу 'products' с количеством строк для каждой связанной таблицы.

Если бы таблицы были настроены обычным образом, 2 таблицы с именами 'транзакция * и ' продукт ' в отношении один ко многим, я мог бы сделать это:

SELECT product, count(*)
FROM product p
INNER JOIN transaction t on p.product_id = t.product_id
GROUP BY product

Однако, он не настроен таким образом, поэтому мне пришлось сделать следующее:

SELECT p.name, p.price, p.id, p.tablename, t.table_rows as Count
FROM products p
INNER JOIN 
    (SELECT table_name, auto_increment
    FROM INFORMATION_SCHEMA.TABLES) t on t.table_name = p.tablename

что не так уж плохо. Так есть ли причина (преимущество), почему использование этой нетрадиционной структуры базы данных может быть полезным? У нас есть несколько таблиц с 3000 транзакций. Я всегда думал, что всегда следует использовать архетипы «один ко многим». Я не хочу спрашивать моего ведущего разработчика, почему он так поступил, чтобы не показаться ему грубым.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...