Рецепт / спецификация MySQL Query

Question

Рецепт / спецификация MySQL Query

0

Я пишу приложение к материалам/рецепту для Minecraft в Node.js, Express, React и MySQL.

У меня есть то, что я считаю хорошей структурой для базы данных с таблицами, но у меня возникает проблема с запросами, которые мне нужно запустить. Вот пример того, что я пытаюсь сделать с примером вывода (я знаю, что рецепт неправильный MC игроков).

Таблица ингредиентов:

RECIPE        || INGREDIENT   || QTY || TYPE
Piston        || Redstone     ||  1  || RM
Piston        || Iron Ingot   ||  1  || RM
Piston        || Wood Planks  ||  3  || RM
Piston        || Stone        ||  4  || RM
Sticky Piston || Piston       ||  2  || CO
Sticky Piston || Slimeball    ||  1  || RM

Я хочу, чтобы при запросе на Sticky Piston была возвращена таблица со всеми необходимыми компонентами, суммированными вместе (сверху) и всеми необходимыми исходными материалами, суммированными вместе (ниже).

Пример Требуемый вывод в формате таблицы или формате JSON:

INGREDIENT   || QTY || TYPE
Piston       ||  2  || CO
Redstone     ||  2  || RM
Iron Ingot   ||  2  || RM
Wood Planks  ||  6  || RM
Stone        ||  8  || RM
Slimeball    ||  1  || RM


[
    {
        "Ingredient": "Piston",
        "Qty": 2,
        "Type": CO
    },
    {
        "Ingredient": "Redstone",
        "Qty": 2,
        "Type": RM
    },
    {
        "Ingredient": "Iron Ingot",
        "Qty": 2,
        "Type": RM
    },
    {
        "Ingredient": "Wood Planks",
        "Qty": 6,
        "Type": RM
    },
    {
        "Ingredient": "Stone",
        "Qty": 8,
        "Type": RM
    },
    {
        "Ingredient": "Slimeball",
        "Qty": 2,
        "Type": RM
    }
]

Я предполагаю, что это ПРИСОЕДИНИТЕСЬ с некоторыми другими причудливыми вещами, которые могут делать все это внутри синтаксиса MYSQL, но я не могу понять это, несмотря на два дня опробовать разные комбинации.

В качестве альтернативы, было бы замечательно, если бы вместо использования синтаксиса MYSQL этот JS использовался, чтобы я мог запускать его на моем сервере Node.js.

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

CREATE TABLE Ingredients
(
  MaterialID    INT unsigned NOT NULL AUTO_INCREMENT,
  Material      VARCHAR(250) NOT NULL,
  MaterialImage VARCHAR(250),
  PRIMARY KEY (MaterialID)
);

CREATE TABLE Recipes
(
  RecipeID      INT unsigned NOT NULL AUTO_INCREMENT,
  Recipe        VARCHAR(250) NOT NULL,
  PRIMARY KEY (ComponentID)
);

CREATE TABLE Recipes_Ingredients
(
  RecipeID      INT unsigned NOT NULL,
  MaterialID    INT unsigned NOT NULL,
  Quantity      INT unsigned NOT NULL
)

Спасибо!

Pap1723 30 июнь 2018, в 21:10

Источник

0

Выглядит как простой запрос без объединения. Просто против рецепт с заказом. Отредактируйте свой вопрос и покажите соответствующие схемы таблиц и их взаимосвязь, если вы действительно считаете, что необходимо объединение. Также добавьте запрос, который вы пробовали
Sloan Thrasher 30 июнь 2018, в 18:43
0

Вы, вероятно, правы, у меня есть другие таблицы, но нет необходимости присоединяться к ним. Я могу легко получить ВЫБЕРИТЕ, ГДЕ Рецепт = тот, который я ищу, но тогда как мне заставить компоненты возвращать их Сырье? А потом сложить количества вместе?
Pap1723 30 июнь 2018, в 19:51
0

Отредактируйте свой вопрос и покажите схему вашей таблицы. Если все, что вам нужно сделать, это сгруппировать по ингредиенту и суммировать количества, это довольно тривиально, но мне нужно увидеть схему таблицы
Sloan Thrasher 30 июнь 2018, в 20:47
1

Вы действительно должны нормализовать свою таблицу ингредиентов. Это означает, что на самом деле не следует делить на 3 таблицы. Таблица ингредиентов и таблица рецептов. Таблицы ингредиентов и получателей будут состоять только из целочисленного идентификатора и имени. В то время как третий стол соединит их. Третья таблица будет содержать идентификатор рецепта и идентификатор материала, используемого для этого рецепта.
Kodos Johnson 30 июнь 2018, в 20:59
0

Кодос, я понимаю, что так и должно быть. Можете ли вы объяснить, почему это нужно сделать именно так? Я не знаю, почему это было бы преимуществом, но я говорю по незнанию непонимания и хотел бы понять, почему это лучше.
Pap1723 30 июнь 2018, в 21:34
0

Извините, я не заметил ваше сообщение до сих пор. Одна из причин, почему это лучше для хранения. Вы повторяете одну и ту же строку снова и снова (т. Е. «Поршень» или «липкий поршень»), которая использует 6+ байтов, каждый из которых умножается на количество используемых строк. Гораздо лучше использовать таблицу «бридж», которая объединяет ингредиенты и рецепты, используя целое число для представления ингредиентов и рецептов (что составляет всего 4 байта для каждой комбинации). Кроме того, что если вы захотите переименовать один из ингредиентов / рецептов? Если вы нормализуетесь, вам нужно будет обновить только одну запись против x количества записей.
Kodos Johnson 03 июль 2018, в 19:54
0

Это имеет смысл @Kodos. Есть ли какая-либо полезная утилита или хитрость, распространенная среди экспертов по базам данных, чтобы легко узнать, к какой информации принадлежат идентификаторы? Я с трудом пытался создать рецепты, когда мне постоянно приходилось искать соответствующий идентификационный номер, но я уверен, что есть более эффективный способ справиться с этим.
Pap1723 04 июль 2018, в 02:24

Показать ещё 5 комментариев

Теги:

mysql

database

javascript

node.js

1 ответ

Ещё вопросы

Выглядит как простой запрос без объединения. Просто против рецепт с заказом. Отредактируйте свой вопрос и покажите соответствующие схемы таблиц и их взаимосвязь, если вы действительно считаете, что необходимо объединение. Также добавьте запрос, который вы пробовали
Вы, вероятно, правы, у меня есть другие таблицы, но нет необходимости присоединяться к ним. Я могу легко получить ВЫБЕРИТЕ, ГДЕ Рецепт = тот, который я ищу, но тогда как мне заставить компоненты возвращать их Сырье? А потом сложить количества вместе?
Отредактируйте свой вопрос и покажите схему вашей таблицы. Если все, что вам нужно сделать, это сгруппировать по ингредиенту и суммировать количества, это довольно тривиально, но мне нужно увидеть схему таблицы
Вы действительно должны нормализовать свою таблицу ингредиентов. Это означает, что на самом деле не следует делить на 3 таблицы. Таблица ингредиентов и таблица рецептов. Таблицы ингредиентов и получателей будут состоять только из целочисленного идентификатора и имени. В то время как третий стол соединит их. Третья таблица будет содержать идентификатор рецепта и идентификатор материала, используемого для этого рецепта.
Кодос, я понимаю, что так и должно быть. Можете ли вы объяснить, почему это нужно сделать именно так? Я не знаю, почему это было бы преимуществом, но я говорю по незнанию непонимания и хотел бы понять, почему это лучше.
Извините, я не заметил ваше сообщение до сих пор. Одна из причин, почему это лучше для хранения. Вы повторяете одну и ту же строку снова и снова (т. Е. «Поршень» или «липкий поршень»), которая использует 6+ байтов, каждый из которых умножается на количество используемых строк. Гораздо лучше использовать таблицу «бридж», которая объединяет ингредиенты и рецепты, используя целое число для представления ингредиентов и рецептов (что составляет всего 4 байта для каждой комбинации). Кроме того, что если вы захотите переименовать один из ингредиентов / рецептов? Если вы нормализуетесь, вам нужно будет обновить только одну запись против x количества записей.
Это имеет смысл @Kodos. Есть ли какая-либо полезная утилита или хитрость, распространенная среди экспертов по базам данных, чтобы легко узнать, к какой информации принадлежат идентификаторы? Я с трудом пытался создать рецепты, когда мне постоянно приходилось искать соответствующий идентификационный номер, но я уверен, что есть более эффективный способ справиться с этим.

Sloan Thrasher · Accepted Answer · 2018-06-30T19-18-00.000Z

UPDATE/EDIT:

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

Я изменил расположение таблицы, чтобы лучше сопоставлять данные, которые вы пытаетесь представить. Поскольку "рецепт" также может быть "материалом", я удалил таблицу рецептов и сохранил эти данные в таблице материалов.

Я также создал SQL Fiddle, чтобы вы могли играть с запросом и точно настраивать результаты.

Первый запрос ниже возвращает все "рецепты" и их компоненты. Чтобы получить только один конкретный рецепт, просто добавьте условие в предложение where, которое выбирает конкретный рецепт.

Если вы предпочитаете иметь компоненты, перечисленные в одном поле, с одной строкой в каждом рецепте, вы можете использовать функцию GROUP_CONCAT и изменить предложение group by.

Второй запрос ниже показывает функцию GROUP_CONCAT. Он также показывает, как изменить недостающие суб-ингредиенты от NULL до "Нет"

SQL Fiddle

MySQL 5.6 Настройка схемы:

CREATE TABLE 'Ingredients'
(
  'MaterialID'      INT unsigned NOT NULL AUTO_INCREMENT,
  'Material'        VARCHAR(250) NOT NULL,
  'MaterialImage'   VARCHAR(250),
  'IsRecipe'        TINYINT(1) DEFAULT 0 NULL,
  PRIMARY KEY ('MaterialID')
);

CREATE TABLE 'Recipes_Ingredients'
(
  'id'              INT unsigned NOT NULL AUTO_INCREMENT,
  'RecipeID'        INT unsigned NOT NULL,
  'MaterialID'      INT unsigned NOT NULL,
  'Quantity'        INT unsigned NOT NULL,
  PRIMARY KEY ('id')
);

INSERT INTO 'Ingredients'
('MaterialID','Material','MaterialImage','IsRecipe')
VALUES
(1,'Redstone','redstone.jpg',0),
(2,'Iron Ingot','ironingot.jpg',0),
(3,'Wood Planks','woodplanks.jpg',0),
(4,'Stone','stone.jpg',0),
(5,'Slimeball','slimeball.jpg',0),
(6,'Piston','piston.jpg',1),
(7,'Sticky Piston','stickypiston.jpg',1),
(8,'Sticky Piston 2','stickypiston2.jpg',1);


INSERT INTO 'Recipes_Ingredients'
('RecipeID','MaterialID','Quantity')
VALUES
(6,1,1),
(6,2,1),
(6,3,3),
(6,4,4),
(7,6,1),
(7,5,1),
(8,6,2),
(8,5,1);

Запрос 1:

SELECT
  a.'MaterialID',
  c.'MaterialID',
  a.'Material' as 'Recipe',
  a.'MaterialImage' as 'RecipeImage',
  c.'Material' as 'Ingredient',
  b.'Quantity' as 'FirstIngredientQuantity',
  c.'MaterialImage' as 'IngredientImage',
  IF(d.'Quantity' IS NULL,SUM(b.'Quantity'),COALESCE(d.'Quantity',0)*b.'Quantity') as 'Quantity',
  e.'Material' as 'Ingredient',
  e.'MaterialImage' as 'MaterialImage'
FROM 'Ingredients' a
LEFT JOIN 'Recipes_Ingredients' b
ON b.'RecipeID' = a.'MaterialID'
LEFT JOIN 'Ingredients' c
ON c.'MaterialID' = b.'MaterialID'
LEFT JOIN 'Recipes_Ingredients' d
ON d.'RecipeID' = c.'MaterialID'
LEFT JOIN 'Ingredients' e
ON e.'MaterialID' = d.'MaterialID' AND c.'IsRecipe' = 1
WHERE a.'IsRecipe' = 1 AND a.'MaterialID' in (7,8)
GROUP BY a.'MaterialID',c.'MaterialID',e.'MaterialID'

Результаты:

| MaterialID | MaterialID |          Recipe |       RecipeImage | Ingredient | FirstIngredientQuantity | IngredientImage | Quantity |  Ingredient |  MaterialImage |
|------------|------------|-----------------|-------------------|------------|-------------------------|-----------------|----------|-------------|----------------|
|          7 |          5 |   Sticky Piston |  stickypiston.jpg |  Slimeball |                       1 |   slimeball.jpg |        1 |      (null) |         (null) |
|          7 |          6 |   Sticky Piston |  stickypiston.jpg |     Piston |                       1 |      piston.jpg |        1 |    Redstone |   redstone.jpg |
|          7 |          6 |   Sticky Piston |  stickypiston.jpg |     Piston |                       1 |      piston.jpg |        1 |  Iron Ingot |  ironingot.jpg |
|          7 |          6 |   Sticky Piston |  stickypiston.jpg |     Piston |                       1 |      piston.jpg |        3 | Wood Planks | woodplanks.jpg |
|          7 |          6 |   Sticky Piston |  stickypiston.jpg |     Piston |                       1 |      piston.jpg |        4 |       Stone |      stone.jpg |
|          8 |          5 | Sticky Piston 2 | stickypiston2.jpg |  Slimeball |                       1 |   slimeball.jpg |        1 |      (null) |         (null) |
|          8 |          6 | Sticky Piston 2 | stickypiston2.jpg |     Piston |                       2 |      piston.jpg |        2 |    Redstone |   redstone.jpg |
|          8 |          6 | Sticky Piston 2 | stickypiston2.jpg |     Piston |                       2 |      piston.jpg |        2 |  Iron Ingot |  ironingot.jpg |
|          8 |          6 | Sticky Piston 2 | stickypiston2.jpg |     Piston |                       2 |      piston.jpg |        6 | Wood Planks | woodplanks.jpg |
|          8 |          6 | Sticky Piston 2 | stickypiston2.jpg |     Piston |                       2 |      piston.jpg |        8 |       Stone |      stone.jpg |

Запрос 2:

SELECT
  a.'MaterialID',
  c.'MaterialID',
  a.'Material' as 'Recipe',
  a.'MaterialImage' as 'RecipeImage',
  c.'Material' as 'Ingredient',
  c.'MaterialImage' as 'MaterialImage',
  SUM(b.'Quantity' + COALESCE(d.'Quantity',0)) as 'Quantity',
  COALESCE(GROUP_CONCAT(CONCAT(e.'Material',' (',b.'Quantity' * d.'Quantity',') [',e.'MaterialImage',']')),'None') as 'Ingredients'
FROM 'Ingredients' a
LEFT JOIN 'Recipes_Ingredients' b
ON b.'RecipeID' = a.'MaterialID'
LEFT JOIN 'Ingredients' c
ON c.'MaterialID' = b.'MaterialID'
LEFT JOIN 'Recipes_Ingredients' d
ON d.'RecipeID' = c.'MaterialID'
LEFT JOIN 'Ingredients' e
ON e.'MaterialID' = d.'MaterialID' AND c.'IsRecipe' = 1
WHERE a.'IsRecipe' = 1
GROUP BY a.'MaterialID',c.'MaterialID'

Результаты:

| MaterialID | MaterialID |          Recipe |       RecipeImage |  Ingredient |  MaterialImage | Quantity |                                                                                                       Ingredients |
|------------|------------|-----------------|-------------------|-------------|----------------|----------|-------------------------------------------------------------------------------------------------------------------|
|          6 |          1 |          Piston |        piston.jpg |    Redstone |   redstone.jpg |        1 |                                                                                                              None |
|          6 |          2 |          Piston |        piston.jpg |  Iron Ingot |  ironingot.jpg |        1 |                                                                                                              None |
|          6 |          3 |          Piston |        piston.jpg | Wood Planks | woodplanks.jpg |        3 |                                                                                                              None |
|          6 |          4 |          Piston |        piston.jpg |       Stone |      stone.jpg |        4 |                                                                                                              None |
|          7 |          5 |   Sticky Piston |  stickypiston.jpg |   Slimeball |  slimeball.jpg |        1 |                                                                                                              None |
|          7 |          6 |   Sticky Piston |  stickypiston.jpg |      Piston |     piston.jpg |       13 | Redstone (1) [redstone.jpg],Iron Ingot (1) [ironingot.jpg],Wood Planks (3) [woodplanks.jpg],Stone (4) [stone.jpg] |
|          8 |          5 | Sticky Piston 2 | stickypiston2.jpg |   Slimeball |  slimeball.jpg |        1 |                                                                                                              None |
|          8 |          6 | Sticky Piston 2 | stickypiston2.jpg |      Piston |     piston.jpg |       17 | Redstone (2) [redstone.jpg],Iron Ingot (2) [ironingot.jpg],Wood Planks (6) [woodplanks.jpg],Stone (8) [stone.jpg] |

Это только возвращает прямые ингредиенты для Липкого поршня, оно не разбивает ингредиенты, также необходимые для изготовления поршня, который является компонентом в липком поршне.
Согласно комментарию @Kodos, ваши данные должны быть нормализованы. Вы не хотите связывать таблицы, используя текстовые значения. Если не 3 таблицы, которые он предложил, то, по крайней мере, уникальный ключ автоинкремента и целочисленный ключ для «подкомпонентов». Связывание строк на основе текстового ключа использует больше ресурсов для каждого запроса и подвержено ошибкам. Например, «Поршень» не равен «поршню». Было бы полезно, если бы ваш вопрос включал схему таблицы. Схема может быть такой же простой, как показ оператора создания таблицы.
ОК, я обновил оригинальный пост с помощью схемы. Надеюсь, это способ организации базы данных.
На основании вашего обновления вашего вопроса, я обновил ответ. Он также предлагает изменить вашу схему и способ хранения данных, что должно повысить производительность и упростить обслуживание данных. Я также создал SQL Fiddle, чтобы вы могли поиграть с двумя запросами.
Это круто! Первый запрос очень близок к тому, что я ищу. Я также ценю скрипку! Единственное, чего не хватает в первом запросе, так это того, что суммы отключены. Они не возвращают правильные суммы для рецепта, и я не могу понять, как это исправить.
Он добавляет по одному количеству сырья, из которого состоит поршень, и не возвращает поршень в качестве необходимого ингредиента.
Смотрите обновленный SQLFiddle . Я также добавил еще один рецепт с двумя поршнями, чтобы проверить математику. Смотрите обновленный ответ выше.
Отлично! Отмечено как принятое, и я проголосовал за вас, но мне не хватает представителя, чтобы показать это. Последний вопрос ... Как я могу сделать так, чтобы я мог передать количество основного рецепта, который бы умножил все значения для суб ингредиентов должным образом?
Это было бы более правильно сделать на языке вызова или в функции или процедуре MySQL.
Спасибо, что приняли, и проголосовали!