Один идентификатор для каждого столбца базы данных, как это сделать?

Question

Я работаю над базой данных продуктов питания, каждый продукт имеет список свойств (жиры, энергия, витамины и т. Д.)

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

Рассмотрим идентификаторы, которые должны содержать число, значение NULL или 0 для одной конкретной ссылки на исключение (будет указывать на другую таблицу)

У меня есть хоть какое-то решение, но они очень разные, и я новичок с db, поэтому я не имею понятия о лучшем решении.

рассматривают значение_1 как белки, значение_2 как углеводы и т. Д.

Лучшие (я надеюсь) 2 альтернативы, которые я подумал:

(1) создать один столбец varchar (255?) Со всеми 50 идентификаторами, примерно так:

column energy              (7.00)
column carbohydrates       (89.95)
column fats                (63.12)
column value_bil_ids       (165862,14861,816486) ## as a varchar
etc...

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

(2) Просто используйте дополнительный столбец id для каждого значения, поэтому:

column energy                 (7.00)
column energy_bibl_id         (165862)
column carbohydrates          (89.95)
column carbohydrates_bibl_id  (14861)
column fats                   (63.12)
column fats_bibl_id           (816486)
etc...

Кажется, что это большое количество столбцов, но сначала очень ясно, особенно для отношения любого столбца значения и его идентификатора.

(3) Создайте реляционную таблицу за значениями и библиографиями, поэтому

table values
energy
carbohydrates
fats
value_id --> point to table values_and_bibliographies val_bib_id


table values_and_bibliographies
val_bib_id
energy_id        --> point to table bibliographies biblio_id
carbohydrates_id --> point to table bibliographies biblio_id
fats_id          --> point to table bibliographies biblio_id


table bibliographies
biblio_id
biblio_name
biblio_year

Я не знаю, являются ли это лучшими решениями, и я буду благодарен, если кто-нибудь поможет мне пролить свет на это!

Answer 1

Вам нужно нормализовать эту таблицу. То, что вы делаете, это безумие, и вы потеряете волосы. Они называются реляционными базами данных, поэтому вы можете делать то, что хотите, без добавления столбцов. Вы хотите структурировать это так, чтобы добавить строки.

Пожалуйста, используйте настоящие имена, и мы можем получить схему.

edit Good edit. № 3 приближается к разумному замыслу. Но вы все еще очень неясно, что делает библиография в схеме питания! Я думаю, что это то, что вы хотите. Вы можете иметь еду и ее компоненты, связанные с библиографией. Я полагаю, что библиография похожа на рецепт?

FOODS 
id name
1   broccoli
2   chicken

COMPONENTS
id name
1   carbs
2   fat
3   energy

BIBLIOGRAPHIES
id  name           year
1  chicken soup     1995


FOOD_COMPONENTS links foods to their components
id  food_id component_id bib_id  value
 1   1         1          1       25 grams
 2   1         2          1       13 onces

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

SELECT * from FOOD_COMPONENTS fc
    INNER JOIN COMPONENTS c on fc.component_id = c.id
    INNER JOIN FOODS f on fc.foods_id = f.id
    INNER JOIN BIBLIOGRAPHIES b on fc.bib_id = b.id
WHERE
    b.name = 'Chicken Soup'

Answer 2

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

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

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

Answer 3

Вот один из подходов, который вы можете использовать для добавления атрибутов в течение всего дня без изменения схемы:

Таблица: еда - каждый ряд - это еда, которую вы описываете

• Id
• Имя
• Описание
• ...

Таблица: атрибут - каждая строка представляет собой числовой атрибут, который может иметь еда

• Id
• Имя
• MinValue
• MaxValue
• Единица (вероятно, «повторяющаяся группа», поэтому технически должна быть в отдельной таблице)

Таблица: библиография - я не знаю, что это такое, но вы делаете

• Id
• ...

Таблица: FoodAttribute - одна запись для каждого экземпляра пищи, имеющей атрибут

• Питание
• Атрибут
• Библиография
• Значение

Так что у вас могут быть следующие записи

• Еда # 1 = чизбургер
• Атрибут № 1 = Жир (Единица = Граммы)
• Библиография # 1 = все, что связано с чизбургерами и жирами

Затем, если в чизбургере содержится 30 граммов жира, в таблице FoodAttribute будет запись: 1 в столбце «Еда», 1 в столбце «Атрибут», 1 в столбце «Библиография» и 30 в столбце «Значение».

(Обратите внимание, что вам могут понадобиться некоторые другие механизмы для работы с нечисловыми атрибутами.)

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

Answer 4

Если вам не нужно формировать запросы на основе произвольных пар ключ / значение, которые вы хотите добавить к каждой записи, вы можете в крайнем случае сериализировать () / unserialize () ассоциативный массив и поместите это в одно поле

Answer 5

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

Предложено (1) Не удастся, если вы хотите добавить столбец. Вы фактически храните все свои столбцы в одном столбце, разделенном запятыми. Bad.

Я не понимаю (2). Звучит так же, как (3)

(3) правильно по духу, но ваш пример запутан и неясен. Сократите свою проблему до простого случая с пятью столбцами или чем-то еще и отредактируйте свой вопрос или сообщение снова.

Короче, не беспокойтесь о количестве столбцов прямо сейчас. Низкий в списке приоритетов.

Answer 6

Почему, ради любви к божеству, вы делаете это по столбцам? Так лежит безумие!

Разложите эту таблицу на строки, затем поместите столбец в каждую строку. Не зная больше о том, что это для и почему это так, трудно сказать больше.

Answer 7

Добавление большего числа столбцов в таблицу не рекомендуется и не популярно в мире БД, за исключением системы NoSQL.

Укажите свои намерения, пожалуйста:)