Как вынуть описание товара из базы данных

Трехтабличный SQL-запрос: извлечение товара и соответстующих ему тэгов

Пример: если хотим вынуть один товар с этих таблиц нужно взять с таблицы tag_post c 1 до 8 например для id_post поста 5 вынуть все айдишники id_tag и с таблицы tag вынуть по этим айдишника теги то получиться один товар типа 1) артикул 2) Вид изделия 3)Материал 4) Основная вставка 5) Производитель нам важно только айдишники до 5

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

Как хранить характеристики товаров в БД и делать поиск по ним?

Есть много поставщиков, их товары надо хранить в БД. Сложность в том, что у товаров много разных характеристик и упорядочить их не получается. На данный момент под них заведено 1 свойство, в котором храниться как есть и поиск делается через LIKE.

Скажите, как в теории можно хранить такие характеристики что бы можно было быстро делать по ним поиск? на данный момент LIKE не справляется. При 6 млн товаров задача подсчитать кол-во товаров по заданной характеристики достигается от несколько сек до десятков секунд.

• Вопрос задан более трёх лет назад
• 3398 просмотров

Комментировать
Решения вопроса 0
Ответы на вопрос 1
Кратко о себе: Я есть

Характеристики относятся к товарам? То есть у одного товара только один набор характеристик или один товар может приходить и продаваться с разными наборами характеристик, например кроссовки адидас, цвет: Белый, размер: 37 и кроссовки адидас, цвет: Синий, размер: 39. Если второй, более сложный случай, то делаем следующие таблицы

1) Таблица Properties (id, name, valueType) — здесь просто храним список возможных свойств
2) Таблица PropertyValues (id, propertyId, value) — здесь храним возможные варианты значений для свойств, у которых не простой тип, то есть не строка, не число, не булево, не дата
3) CharacteristicsSet (id, productId, name) — здесь будет храниться набор свойств для конкретной позиции товара на складе, name будет составляться автоматически как строка из свойств и их значений, указанных для позиции товара
4) CharacteristicsValues (chartacteristicSetId, propertyId, valueType, value) — здесь будут храниться значения свойств для конкретной характеристики.

Например нам пришли партии кроссовок со свойствами цвет: белый, размер: 37й и цвет: синий, размер: 39й. (например 100 и 50 штук соответственно)

Тогда наши таблицы будут выглядеть следующим образом:

Properties:
id: 1, property: ‘Цвет’, valueType: ‘set’
id: 2, property: ‘Размер’, valueType: ‘number’

PropertyValues:
id: 1, propertyId: 1, value: ‘Белый’
id: 2, propertyId: 1, value: ‘Красный’
id: 3, propertyId: 1, value: ‘Синий’

CharacteristicsSet:
id: 1, productId: 777, name: ‘Цвет: белый, размер: 37’
id: 2, productId: 777, name: ‘Цвет: синий, размер: 39’

CharacteristicsValues
chartacteristicSetId: 1, propertyId: 1, valueType: set, value: 1(ссылка на белый цвет)
chartacteristicSetId: 1, propertyId: 2, valueType: number, value: 37
chartacteristicSetId: 2, propertyId: 1, valueType: set, value: 2(ссылка на синий цвет)
chartacteristicSetId: 2, propertyId: 2, valueType: number, value: 39

Ну и в таблице склада можно будет хранить записи в виде:
productId: 777, characteristicsSetId: 1, quantity: 100
productId: 777, characteristicsSetId: 2, quantity: 50

Если же различный набор свойств для одного товара нам не нужен, то все то же самое, но обходимся без таблицы CharacteristicsSet: а в CharacteristicsValues ссылаемся на сам товар. Соответственно весь поиск будет проходить по одной таблице CharacteristicsValues с индексированными полями. Например чтобы найти любые товары с цветом Белый, мы делаем поиск

select * from CharacteristicsValues where propertyId = 1 and value = 1

ну и с соответствующим соединениям по таблицам характеристик и(или) товаров

Как получить информацию о структуре БД для документации

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

Это поможет любому участнику команды, а в первую очередь системному аналитику, решить такие задачи:

• Корректно сформулировать задачу на доработку системы в ситуации, когда её БД не описана
• Оценить актуальность имеющейся документации на БД
• Выполнить инвентаризацию информационных ресурсов
• Проводить мониторинг состояния БД на проекте

Время на чтение статьи: 14 минут
Оглавление

Какие метаданные полезно знать о своей БД?

При работе над любым ИТ-проектом полезно иметь возможность посмотреть на данные своих систем с высоты птичьего полёта.

Вот какая информация пригодится вам в первую очередь.

• Физическая структура данных: объекты БД (в первую очередь — таблицы и поля, их наименования, типы данных, допустимые диапазоны значений, ключи, а также — пользователи, индексы, представления и т. п.)
• Объём данных, частота их обновления, дата последнего обновления БД
• Модель данных (логическая, концептуальная) — ключевые атрибуты и сущности, связь между ними
• Смысл и значение данных, объяснение основных сущностей на языке бизнеса
• Распределение данных (количество пустых полей, кардинальность (количество уникальных и повторяющихся значений)
• Ответственный за данные — кто может пояснить смысл данных или помочь исправить найденные проблемы в них

Что такое словарь данных и зачем он нужен

Мы будем подразумевать под «словарем данных» (англ. — data dictionary) справочник или централизованное описание метаданных, дающее представление о структуре и содержании данных. У этого термина есть и другое значение, в рамках данной статьи не используемое: словарём данных называют технику моделирования, дополняющую требования при проектировании информационных систем, в культуре Systems Analysis and Design.

Мы все знаем, что в целостном и удобном для использования виде найти такую информацию по своему проекту аналитику бывает непросто. Структура таблиц базы данных попросту не описана в документации. Почему же так происходит?

Почему так редко задумываются о документировании БД?

• Это самая неинтересная для программистов часть

• На старте проекта БД создаётся по интуиции и видению разработчиков

• Для данных редко выделяется отдельный архитектор или просто ответственное лицо в команде

• По мере роста проекта требования к БД сложно выделить из множества требований на доработку

Вначале всё кажется очевидным, но по мере роста проекта оказывается, что единого описания данных и их структуры не существует, также как и носителя информации об этом среди участников команды. Иногда оказывается, что устройство БД уже усложнилось до такой степени, что приходится организовывать целую исследовательскую экспедицию для восстановления этой информации. В идеале нужно поддерживать актуальность информации о данных системы, и делать это можно разными способами.

Какие средства документирования можно применять для описания БД?

Инструмент, тип документации	Какую информацию можно найти	Примеры и комментарии	Что почитать
Специальные платформы управления данными Data Management.	•‎ Каталог данных (Data Catalog) — единый источник сведений о всех информационных активах организации. •‎ Список полей и атрибутов •‎ Метаданные — например, информацию о размере таблиц, дате последнего обновления •‎ Информацию об ответственных лицах •‎ Бизнес-глоссарий	Дороги в применении, используются в крупных только в больших компаниях, актуальны для проектов создания DWH (централизованное персистентное хранение данных всего предприятия для аналитики).	Что такое каталог данных? Видео от DIS Group

Как вы уже поняли, если перед вами стоит задача понять смысл и структуру данных вашей системы, то придётся обращаться к нескольким источникам. Рыться в документации полезно, но утомительно. Наверно, вам уже пришла в голову мысль, что лучший способ понять вашу базу данных «as is» будет заключаться в том, чтобы подключиться к ней и «пощупать её руками».

Источники информации о БД

Как можно получить информацию о данных, используемых в системе?

Способ	Описание	Пример
Использовать специализированные инструменты, обеспечивающие возможность просмотра объектов БД.	Способ позволит визуально быстро понять, какие объекты есть в вашей базе данных. Можное осмотреть список таблиц и о каждой из них узнать что-то из контекстного меню или другой части внутри GUI используемого средства. Однако, получать, хранить и передавать информацию в такой форме неудобно.	Документация к редактору объектов DBeaver
Вывести информацию об объектах БД с помощью соответствующих SQL запросов к служебным таблицам.	В РСУБД существуют служебные таблицы, которые содержат интересующие нас сведения об объектах базы данных. Вы можете строить несложные SQL запросы к служебным таблицам и системным каталогам БД (помимо таблиц со схемой, среди служебных таблиц обычно есть много интересного).	Использование схемы данных в SQL Server

Не все из перечисленных способов могут быть доступны аналитику. Например, возможность просмотра полной схемы БД бывает ограничена только для администраторов, а построение запросов к служебным таблицам требует знания особенностей конкретной СУБД. В следующих частях статьи вы найдёте примеры таких запросов и сможете начать использовать их прямо сейчас.

Как получить информацию о БД

Как быстро получить словарь данных для популярных БД?

Несколько слов по данному вопросу от Александра Кротова.

Полагаю, многие системные и бизнес-аналитики сталкивались с задачей инвентаризации информационных ресурсов организации, то есть с работой по описанию имеющихся в наличии автоматизированных систем, баз данных, локальных АРМ-ов и других ИТ-объектов, играющих определённую роль в бизнес-процессах. Как правило, такие работы проводятся в целях анализа состояния и эффективности ИТ-инфраструктуры внутри компании или на стороне заказчика, либо на фазе обследования в проектах, связанных с доработкой существующих систем. Зачастую работа по документированию текущего состояния дел возлагается на системного аналитика или бизнес-аналитика. В этой статье мы не будем обсуждать всё, что может быть связано с подобной инвентаризацией, а остановимся на подходах к обследованию одного типа ИТ-ресурсов компании — её баз данных.

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

Что делать в такой ситуации? Первое, что пришло бы мне в голову, это провести для всех баз данных так называемый «реверс-инжиниринг» (reverse engineering). Можно было бы изучить имеющиеся данные и их структуру, взять могучее универсальное средство моделирования, построить ER-модели, сформировать текстовое описание и приступить к более глубокому анализу полученных материалов. Но здесь мы можем натолкнуться на ряд проблем: универсальные средства моделирования, способные работать с разными СУБД, стоят, как правило, дорого, и далеко не каждый работодатель будет готов потратить деньги на приобретение подобного программного продукта. А вероятность того, что в процессе инвентаризации информационных ресурсов придётся столкнуться с так называемым «зоопарком», то есть разбродом и шатанием в платформах, СУБД и их версиях, достаточно высока. Иначе и задача наведения порядка в информационном хозяйстве вообще вряд ли бы возникла.

И вот, в ситуации, когда «зоопарк» есть, а актуальной документации и подходящего инструмента для её создания нет, можно пойти по другому пути и попробовать сформировать необходимую для анализа документацию на основе так называемых «словарей данных» — служебных таблиц, в которых реляционная (и не только) СУБД хранит описание своих объектов — таблиц, полей, представлений, ключей, индексов и многого другого. В том или ином виде такие словари должны быть в любой СУБД, хотя структура их может сильно различаться. В общем, я решил посмотреть, как подобные словари устроены, взяв для примера несколько популярных СУБД: MySQL, PostgreSQL, Oracle, SQLite, MS Access. А задачу я себе поставил простую: для каждой СУБД написать SQL-запрос, который сформирует описание таблиц и полей выбранных баз данных. Только хотел бы предупредить, что для разных версий одной и той же СУБД запросы могут немного отличаться, но, думаю, это и так очевидно.

Словарь данных для MySQL

Начал я с MySQL. Здесь всё оказалось достаточно просто. Можно использовать стандартную схему под названием INFORMATION_SCHEMA (говорят, даже ANSI на неё свой стандарт оформила для разных СУБД). Схема содержит таблицы, в которых можно легко найти все необходимые метаданные. В нашем случае достаточно соединить таблицы TABLES (таблицы) и COLUMNS (поля) по именам схемы и таблицы, выбрать нужные атрибуты, присвоить понятные псевдонимы, задать условия выборки (например, по имени схемы и типу объектов, как на примере ниже). Получится примерно такой запрос:

Получим результат вот такого вида
(показано на фрагменте отчёта для учебной БД «Студенты»):

Таблица	Комментарий к таблице	№ п.п	Поле	Комментарий к полю	Тип	Ключ	NULL
EMPLOYEE	Сотрудники	1	ID	Идентификатор	int(11)	PK	NO
EMPLOYEE	Сотрудники	2	LAST_NAME	Фамилия	varchar(45)	NO
EMPLOYEE	Сотрудники	3	FIRST_NAME	Имя	varchar(45)	NO
EMPLOYEE	Сотрудники	4	MIDDLE_NAME	Отчество	varchar(45)	YES
EMPLOYEE	Сотрудники	5	BIRTHDAY	День рождения	date	YES
GRADE	Оценки	1	ID	Идентификатор	int(11)	PK	NO
GRADE	Оценки	2	STUDENT_ID	ИД студента в группе	int(11)	YES
GRADE	Оценки	3	MODULE_NUM	Номер модуля	int(11)	YES
GRADE	Оценки	4	GRADE	Оценка	int(11)	YES
GROUP_ST	Учебные группы	1	ID	Идентификатор	int(11)	PK	NO
GROUP_ST	Учебные группы	2	GROUP_CODE	Код группы	varchar(45)	YES
GROUP_ST	Учебные группы	3	TEACHER_ID	ИД сотрудника-преподавателя	int(11)	YES
GROUP_ST	Учебные группы	4	CURATOR_ID	ИД сотрудника-куратора	int(11)	YES
STUDENT	Студенты	1	ID	Идентификатор	int(11)	PK	NO
STUDENT	Студенты	2	LAST_NAME	Фамилия	varchar(45)	NO
STUDENT	Студенты	3	FIRST_NAME	Имя	varchar(45)	NO
STUDENT	Студенты	4	MIDDLE_NAME	Отчество	varchar(45)	YES
STUDENT	Студенты	5	BIRTHDAY	День рождения	date	YES

Единственное, надо не забывать, что запрос вернёт только те объекты БД, на просмотр которых у текущего пользователя есть привилегии. И ещё я бы обратил внимание на атрибут ORDINAL_POSITION, который был использован в составе оператора ORDER BY после TABLE_NAME (имя таблицы). Атрибут предназначен для хранения порядка полей, заданного в DDL-скрипте при создании таблицы (оператор CREATE TABLE) или установленного разработчиком позже (кстати, возможность изменять порядок полей после создания таблицы реализована далеко не во всех СУБД, MySQL здесь обогнал многих). Но зачем хранить исходный порядок полей, если теория реляционных баз данных утверждает, что порядок полей в таблице не несёт никакой смысловой нагрузки? Полагаю, эта возможность реализована исключительно для удобства пользователя. Разработчик, создавая таблицу, задаёт порядок полей не просто так, а на основе определённой бизнес-логики, и вправе ожидать, что выполнив запрос типа SELECT * FROM … без явно указанного порядка полей, или создав отчёт на основе словаря данных, как мы это сделали выше, он получит поля в порядке, соответствующем заложенной логике, а не как попало. Аналогичные по сути атрибуты с порядковым номером поля в таблице, есть и в других СУБД, что мы увидим ниже.

Как организовать структуру базы данных для характеристик товаров магазина?

Необходимо в БД хранить характеристики товаров.
Вот 2 таблицы

Т.е. есть 2 таблицы.
Первая таблица «характеристика», вторая возможные значения.
Основная проблема в том, что характеристики бывают нескольких типов. Для этого добавили в таблицу характеристик поле «type» (тип может быть ‘checkbox’,’radiobutton’,’multiselect’,’text’).
К примеру, если характеристика имеет тип checkbox (например «GPS» имеет значение либо true, либо false), то приходится в таблице значений хранить true и false для этой характеристики. Таких характеристик очень много и для каждой мы храним true и false в таблице значений. Как можно этого избежать, либо это нормально?

• Вопрос задан более трёх лет назад
• 7235 просмотров