2017-02-12 2 views
-1

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

Table 1: "Region" 
Columns: "Houses", "Apartments" 

Table 2: "Appliances" 
Columns: "Fridge", "Washer" 

В этом состоянии, шайбы не допускаются в жилых единицах, поэтому точка этой базы данных будет знать, что связано, не обязательно, чтобы вставить значения под колоннами. При создании формы поиск самого маленького общего знаменателя покажет мне все, с чем связано. В этом случае, если я буду искать «Шайбу» -> «Дома», в результате, НЕ квартиры. В то время как поиск «Холодильник» дал бы мне как «Дома», так и «Апартаменты». Очевидно, что это простой пример, и у реальной базы данных будет намного больше деталей, и это даже не связано с этим.

Поскольку я новичок в этом, мне нужно знать, как его проектировать. В этом контексте мне даже не нужны строки под каждым столбцом: «Дома», «Апартаменты», «Холодильник», «Стиральная машина», так как я не буду вставлять туда ценности. Я хочу только фильтровать сложные относительные данные.

Каково значение только для построения таблиц и столбцов (без строк)? Это правильный дизайн? Будет ли он работать правильно? И как я могу создавать запросы таким образом? Что ты предлагаешь?

+1

Этот дизайн ничего, но правильная реляционная конструкция. Кажется, вы пытаетесь реализовать какую-то конфигурацию? Если это так, то это обычно делается в одной таблице, причем «region» и «appliance» являются столбцами, а «апартаменты» и «шайба» являются значениями в строке (например) –

+0

@SergioTulentsev благодарит за ответ. Я запутался, потому что данные будут статичными, и я собираюсь использовать запросы, чтобы видеть отношения между значениями. В вашем примере я бы дважды написал «Холодильник» (см. Ниже). Есть ли лучший способ избежать этого? Я понимаю, что базы данных были разработаны для сброса информации без проверки общих значений, но это не первый случай, когда кто-то пытается это сделать. Ваше предложение: *** Столбец 1: Апартаменты | Ценности: Холодильник *** *** Столбец 2: Дома | Значения: Холодильник, Стиральная машина *** – Alex

+0

В базе данных будет смысл, что значение, которое больше всего отображается в строках, должно быть общим знаменателем или корнем иерархии (aka column) и поэтому должно быть записано как можно меньше , Я не сумасшедший, не так ли ?! – Alex

ответ

1

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

Table 1: "Region" 
Columns: "Id", "Name" 
Row: 1 , Houses 
Row: 2 , Apartments 

Table 2: "Appliance" 
Columns: "Id", "Name" 
Row:  1 , Fridge 
Row:  2 , Washer 

Table 3: "RegionApplianceCombination" 
Columns: "ApplicanceId", "RegionId" 
Row:     1 ,   1 
Row:     2 ,   1 
Row:     1,   2 

Вы можете запросить это, как это - для всех приборов, разрешенных в дома:

select Region.Name, Appliance.Name 
from Region 
inner join RegionApplianceCombination on Region.Id = RegionId 
inner join Appliance on Appliance.Id = ApplicanceId 
where Region.Name = "Houses" 

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

select Region.Name, Appliance.Name 
from Region 
inner join RegionApplianceCombination on Region.Id = RegionId 
inner join Appliance on Appliance.Id = ApplicanceId 
where Appliance.Name = "Fridge" 

Вы можете запросить это, как это, чтобы проверить, если такое сочетание разрешено:

select Region.Name, Appliance.Name 
from Region 
inner join RegionApplianceCombination on Region.Id = RegionId 
inner join Appliance on Appliance.Id = ApplicanceId 
where Appliance.Name = "Washer" and Region.Name = "Apartments" 
+0

Спасибо! Теперь я начинаю понимать, что мне придется очень активно использовать * ссылки *. – Alex

+0

Можете ли вы объяснить мне, почему вам нужно создать третью таблицу и почему система не будет делать это автоматически при создании табличных отношений? Другими словами, какова цель отношений с таблицами, если вам нужно вручную выполнить таблицу 3? – Alex

+0

Nevermind, я только что узнал о составных таблицах и что многие-ко-многим иногда невозможно. Поскольку будет множество составных таблиц, возможность даже больше, чем сама информация. Я думаю, мне лучше найти базу данных, которая делает много для многих. Спасибо друг! – Alex

Смежные вопросы