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

Question

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

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

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

Я хоть какое-то решение, но они очень разные eachothers, и Я новичок с 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... 

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

(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... 

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

(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

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

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

Редактировать Хорошее редактирование. # 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

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

Выработать ваши намерения, пожалуйста :)

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

Таблица: Продукты питания - каждая строка представляет собой пищевой продукт вы описываете

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

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

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

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

• Id
• ...

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

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

Таким образом, вы, возможно, следующие записи

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

Тогда, если чизбургер имеет 30 грамм жира, будет запись в таблице FoodAttribute с 1 в столбце Food, 1 в столбце Attribute, 1 в столбце Bibliography и 30 в столбце Value.

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

Читайте Modeling о данных и базы данных Нормализация для получения дополнительной информации о том, как подходить к такого рода проблем .. .

Answer 6

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

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

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

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

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

Answer 7

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