все привет начал тему, видимо мало кто что понял из нее
http://phpforum.su/index.php?showtopic=87374&hl=
упрощу вопрос и попробую сначала
у нас есть 10 таблиц из них нужно получить данные
что лучше в плане нагрузки и скорости работы создать 1 сложный запрос за счет join или получить с каждой таблицы информацию отдельно, а потом собрать в месте в нужном виде?
Полная Версия: получение инофрмации часть 2
А почему в той теме не отписаться?!
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
inpost
да я фз, могу перенести инфу в ту тему
да я фз, могу перенести инфу в ту тему
hurt3
Для маленьких таблиц без разницы. Для огромных - лучше оба варианта лично попробовать. Иногда отдельные запросы работают быстрее, чем тот же JOIN. А может в итоге вообще в 11-ую таблицу кидать результат и её сделать кешем данных
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
Для маленьких таблиц без разницы. Для огромных - лучше оба варианта лично попробовать. Иногда отдельные запросы работают быстрее, чем тот же JOIN. А может в итоге вообще в 11-ую таблицу кидать результат и её сделать кешем данных
_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
inpost
ну понятно спасибо
ну понятно спасибо
Я думаю надо сделать пару подходов к снаряду проектирование БД и спроектировать ее по человечески. Если все таки не найдется лучшей идеи чем предложенная то мысля логически стоит сделать join + index потому что сделать 10 запросов а потом с помощью ПО разбираться с результатами не стоит.
_____________
Трус не играет в хокей
_____________
Трус не играет в хокей
какое решение структуры базы данных вы можете предложить в данном случае?
| Цитата |
| Добрый день. Подскажите правильно ли организована бд и какой способ извлечения информации лучше. Ситуация следующая существует абстрактный объект тип товара, тип товара может обладать различными свойствами, но эти свойства предопределены, и пользователь при создании нового типа товара выбирает, какие свойства необходимо присвоить новому типу товара. Пользователей много, и каждый может создать неограниченное количество типов товара Планируется организовать бд следующим образом: для каждого свойства отдельная таблица и отдельная таблица связи конкретного свойства с конкретным созданным товаром |
А что будет в таблице свойства?
Для чего аж целую таблицу под одно свойство?
Моё видиние такое:
property
p_id;
p_name;
p_что_то_там_еще;
typ
t_id;
t_name;
t_.....;
typ_property
tp_id; // по желанию.
t_id;
p_id;
Наверняка у свойства могут быть значения.
Например, цвет: красный, синий, зеленый. Размер: S, M, L, XL и т.д.
Но некоторые разные свойства могут иметь схожие наборы значений (масса кг. 1 / 2 / 3 Сорт 1 / 2 / 3 и т.д.)
Тогда делаем еще 2 таблицы
values_values
v_id;
v_value; // красный, XL, 3 и т.д.
И, собственно, связь свойства и значений свойства.
property_value
p_id; // свойство
v_id; // значение
Можно еще одну таблицу забабахать, описывающую "правила" для свойств, чтобы не получилось, что цвет XL, а давать только выбирать значения для свойства.
На коленках писано
Лучше всего возьми листик с ручкой или редактор диограмм и там разрисуй
_____________
[продано копирайтерам]
AllesKlar
я правильно вас понял, вы предлагаете все значения свойств сложить в одну таблицу? а не распределять по 10ке таблиц? это не повлияет на скорость работы допустим при поиске?
я правильно вас понял, вы предлагаете все значения свойств сложить в одну таблицу? а не распределять по 10ке таблиц? это не повлияет на скорость работы допустим при поиске?
смысл в том что типы свойств известны и для хранения информации конкретного свойства предполагалось использовать отдельную таблицу, в первую очередь это делалось для ускорения работы при поиске, а так же для хранения разных свойств применяются различные типы ячеек таблицы, т.е. одно свойство может быть текстом, второе числом, с этим то как быть?
hurt3 прочитай про паттерн EAV (Entity-Attribute-Value).
| Цитата (hurt3 @ 7.09.2015 - 06:23) |
| одно свойство может быть текстом, второе числом |
Таблицы значений заводятся под каждый тип данных. а не под каждый атрибут, как у тебя.
kaww
да это понятно, но хотелось бы разнести базу по логике приложения, а не по существу
да это понятно, но хотелось бы разнести базу по логике приложения, а не по существу
и так господа с учетом всего выше сказанного, как все же лучше организовать базу данных?
вопрос все еще актуален.
какое из предложенных решений является более оптимальным?
для каждого товарного объекта создавать отдельную таблицу и иметь возможность вносить новые ячейки тем самым добавляя и удаляя свойства товара или же использовать EAV (Entity-Attribute-Value) где как писал kaww Таблицы значений заводятся под каждый тип данных
какое из предложенных решений является более оптимальным?
для каждого товарного объекта создавать отдельную таблицу и иметь возможность вносить новые ячейки тем самым добавляя и удаляя свойства товара или же использовать EAV (Entity-Attribute-Value) где как писал kaww Таблицы значений заводятся под каждый тип данных
Здесь расположена полная версия этой страницы.