Слишком много таблиц; MySQL может только использовать 61 таблицу в соединении

Question

Слишком много таблиц; MySQL может только использовать 61 таблицу в соединении

Для C# решение состоит в том, чтобы бросить значения к двойному (как Математика. Потолок берет двойное):

int nPages = (int)Math.Ceiling((double)nItems / (double)nItemsPerPage);

В Java необходимо сделать то же с Math.ceil ().

11

mysql join entity-attribute-value

задан Brian Tompsett - 汤莱恩 18 January 2017 в 20:13

2 ответа

Если у вас так много атрибутов, я полагаю, что это разреженная база данных, поэтому у вас много потраченного впустую места.

Вы можете использовать Entity-Attribute -Значение вместо этого, если возможно.

http://en.wikipedia.org/wiki/Entity-attribute-value_model

Это дает вам возможность реорганизовать базу данных, но сделать ее более расширяемой, и уменьшите количество необходимых столов. У вас должно получиться до 4-6 таблиц (2-3 таблицы сущностей с их атрибутами). Создавать запросы немного сложнее, так как все запросы будут динамическими, но это упростит ваш экспорт, а обслуживание базы данных должно быть проще.

Если вам необходимо использовать эту схему, вы можете создать несколько триггеров и затем вы можете вызвать триггер, который объединяет несколько таблиц, а затем сделать свой запрос, Как развернуть схему MySQL entity-attribute-value Как развернуть схему MySQL сущность-атрибут-значение

2

ответ дан 3 December 2019 в 04:13

Другие вопросы по тегам:

mysql join entity-attribute-value

Похожие вопросы:

score 22 · Accepted Answer

Вы используете дизайн EAV и пытаетесь воссоздать одну строку из переменного числа атрибутов. Это указывает на одну из многих наземных мин, с которыми вы столкнетесь при использовании конструкции EAV: существует практическое ограничение на количество соединений, которые вы можете выполнить в одном запросе SQL.

Особенно в MySQL - как вы выяснили, существует жесткое ограничение. Но даже в других брендах РСУБД существует эффективное ограничение, поскольку стоимость объединений геометрическая по отношению к количеству таблиц.

Если вы используете EAV, не пытайтесь воссоздать строку в SQL , как если бы у вас была обычная база данных. Вместо этого выберите атрибуты в виде строк, отсортированных по идентификатору объекта. Затем обработайте их в коде вашего приложения. Это действительно означает, что вы можете ' • выгрузить данные за один шаг - вам нужно написать код, чтобы перебирать строки атрибутов и преобразовывать каждую строку данных, прежде чем вы сможете вывести ее.

EAV не является удобным дизайном базы данных. У его использования много дорогостоящих недостатков, и вы только что столкнулись с одним из них.

См. http://www.simple-talk.com/opinion/opinion-pieces/bad-carma/ ], чтобы узнать, как использование EAV обрекло один бизнес.

А также см. http://en.wikipedia.org/wiki/Inner-platform_effect , потому что EAV является примером этого антипаттерна. .

Я понимаю необходимость поддержки динамического набора атрибутов для каждого продукта в каталоге. Но EAV убьет ваше приложение. Вот что я делаю для поддержки динамических атрибутов:

Определите настоящий столбец в базовой таблице для каждого атрибута, общего для всех типов продуктов. Наименование товара, цена, количество на складе и т. д. Трудно представить себе каноническую сущность продукт , чтобы вы могли включить в этот набор как можно больше атрибутов.
Определите еще один столбец типа TEXT ] для всех дополнительных атрибутов каждого данного типа продукта. Сохраните в этом столбце как Сериализованный LOB атрибутов в любом удобном для вас формате: XML, JSON, YAML, ваш собственный самодельный DSL и т. Д.

Рассматривайте это как отдельный столбец в ваших SQL-запросах. Любой поиск, сортировка или отображение, которые вам нужно выполнить на основе этих атрибутов, требует, чтобы вы извлекли весь большой двоичный объект TEXT в свое приложение, десериализовали его и проанализировали атрибуты с помощью кода приложения.