ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / одно поле -> две таблицы. Что подскажет опыт?
25 сообщений из 35, страница 1 из 2
  1  все
одно поле -> две таблицы. Что подскажет опыт?
    #32152060
kondi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kondi
Гость
Имеем: изделия, сырье, полуфабрикаты и рецептуры продуктов и изделий

Как было сделано мной на Clipper-е
Таблица Prod – изделия (поля: ID_Prod, Name_Prod)
Таблица Raw – сырье и полуфабрикаты (ID_Raw, Name_Raw)
Таблица RcProd – рецептуры изделий (ID_Prod, Flag_RP_Comp, ID_RP_Comp, Weight)
Таблица RcRaw – рецептуры полуфабрикатов (ID_Raw, Flag_RP_Comp, ID_RP_Comp, Weight)

Т.е. рецептура изделия может содержать как сырье (и полуфабрикаты), так и изделия, например для рецептур наборов изделий (т.е. набор являясь изделием сам состоит из готовых изделий) Поле ID_RP_Comp в зависимости от значения поля Flag_RP_Comp ссылается на ID_Raw из Raw, или на ID_Prod из Prod. Аналогично рецептура полуфабриката может включать готовое изделие.

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

Хочу при переходе на SQL Server предоставить эти заботы самой СУБД.

Выхода вижу два
1) слить все в 2 таблицы
Таблица RP – изделия, сырье и полуфабрикаты (ID_RP, Name_RP, Flag_RP)
Таблица RcRP – рецептуры (ID_RP, ID_RP_Comp, Weight)

Для удобства работы сделать представления для RP используя поле Flag_RP, чтобы готовые изделия, полуфабликаты и сырье оказались в разных представлениях.

2) изменить структуру таблиц с рецептурами
Таблица RcProd – рецептуры продуктов (ID_Prod, ID_Raw_Comp, ID_Prod_Comp, Weight)
Таблица RcRaw – рецептуры полуфабрикатов (ID_Raw, ID_Raw_Comp, ID_Prod_Comp, Weight)

Тогда ID_Raw_Comp будет ссылаться на ID_Raw из Raw, а ID_Prod_Comp на ID_Prod из Prod, конечно одно из этих полей должно быть равно NULL

Спасибо всем кто дочитал.
Как вы сами выходили из подобной, довольно распространенной, ситуации и что посоветуете исходя из своего опыта?
...
Рейтинг: 0 / 0
30.04.2003, 16:01
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152234
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cat2
Модератор форума
Первый вариант мне нравится больше.
В принципе, все можно сделать на одной таблице, иерархической структурой, но будут сложные запросы.
...
Рейтинг: 0 / 0
30.04.2003, 19:19
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152280
kondi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kondi
Гость
Иерархической не пойдет. Она циклическая.

В рецептуру изделия может входить само это изделие.

Речь идет о продуктах питания, а случай "сам входит в свою рецептуру" это использование в рецептуре возвратных отходов (например крошки) самого изделия.

Аналогично и для полуфабрикатов.
...
Рейтинг: 0 / 0
30.04.2003, 22:04
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152284
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cat2
Модератор форума
Иерархическая структура не будет циклической, если Вы только сами ее не сделаете таковой.

Крошка - это все таки не изделие, а ингридиент.
========
Но я не говорю, что это лучший вариант. Это один из возможных.
Тут большое значение имеет, на какую глубину идет вложеность.

Пример на три уровня вложенности

Изделие ->

Ингридиент1
Ингридиент2

------------
Ингридиент1 ->

Ингридиент4
Ингридиент5


------------
Ингридиент4 ->

Ингридиент6
Ингридиент7

==========
Я так думаю, что в Вашем случае уровень вложенности не может превышать 2. И это можно будет сделать по Вашему варианту 2 через самосоединение таблиц.
+++++++++++++++++++++++
Ну не могу я частенько объяснить, почему мне что-то кажется лучшим, чем другое. Просто я так вижу.
...
Рейтинг: 0 / 0
30.04.2003, 22:54
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152320
Фотография Andrew Campball
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrew Campball
Участник
Давайте разберемся с таким раскладом:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
Изделие  1 
  |
  + -- Рецепт 1
 
  |      |
  |      + -- Полуфабрикат 1
 
  |      |      |
  |      |      + -- Сырье 1
 
  |      |      |
  |      |      + -- Сырье 2
 
  |      |      
  |      + -- Полуфабрикат 2      
 
  |      |      |
  |      |      + -- Сырье 3
 
  |      |      |
  |      |      + -- Сырье 4
 
  |      |      
  |      + -- СЫрье 7      
 
  |      |      
  |      + -- Изделие 2
 
  |             
  +  -- Рецепт 2             
 
  |      |      
  |      + -- Полуфабрикат 1
 
  |      |      |
  |      |      + -- Сырье 1
 
  |      |      |
  |      |      + -- Сырье 2
 
  |      |      
  |      + -- Полуфабрикат 4
 
  |             |
  |             + -- Сырье 3
 
  |             |
  |             + -- Сырье 7
 
  и т.д.


В итоге имеем следующие таблицы:

RAW_MAT (ID, NAME) - Сырье

PREP_MAT (ID, NAME) - Полуфабрикат

PREP_MAT_RAW (PREP_MAT_ID, RAW_MAT_ID) - Состав полуфабриката


RECIPE(ID, NAME) - Рецепт

RECIPE_PREP_MAT(RECIPE_ID, PREP_MAT_ID, RAW_MAT_ID, PROD_ID) - Состав рецепта


PRODUCTION (ID, NAME) - Изделие

PRODUCT_RECIPE (PROD_ID, RECIPE_ID) - Рецепты приготовления
...
Рейтинг: 0 / 0
01.05.2003, 08:45
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152321
Фотография Andrew Campball
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrew Campball
Участник
Давайте разберемся с таким раскладом:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
Изделие  1 
  |
  + -- Рецепт 1
 
  |      |
  |      + -- Полуфабрикат 1
 
  |      |      |
  |      |      + -- Сырье 1
 
  |      |      |
  |      |      + -- Сырье 2
 
  |      |      
  |      + -- Полуфабрикат 2      
 
  |      |      |
  |      |      + -- Сырье 3
 
  |      |      |
  |      |      + -- Сырье 4
 
  |      |      
  |      + -- СЫрье 7      
 
  |      |      
  |      + -- Изделие 2
 
  |             
  +  -- Рецепт 2             
 
  |      |      
  |      + -- Полуфабрикат 1
 
  |      |      |
  |      |      + -- Сырье 1
 
  |      |      |
  |      |      + -- Сырье 2
 
  |      |      
  |      + -- Полуфабрикат 4
 
  |             |
  |             + -- Сырье 3
 
  |             |
  |             + -- Сырье 7
 
  и т.д.


В итоге имеем следующие таблицы:

RAW_MAT (ID, NAME) - Сырье

PREP_MAT (ID, NAME) - Полуфабрикат

PREP_MAT_RAW (PREP_MAT_ID, RAW_MAT_ID) - Состав полуфабриката


RECIPE(ID, NAME) - Рецепт

RECIPE_PREP_MAT(RECIPE_ID, PREP_MAT_ID, RAW_MAT_ID, PROD_ID) - Состав рецепта


PRODUCTION (ID, NAME) - Изделие

PRODUCT_RECIPE (PROD_ID, RECIPE_ID) - Рецепты приготовления
...
Рейтинг: 0 / 0
01.05.2003, 08:45
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152322
Фотография Andrew Campball
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrew Campball
Участник
Давайте разберемся с таким раскладом:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
Изделие  1 
  |
  + -- Рецепт 1
 
  |      |
  |      + -- Полуфабрикат 1
 
  |      |      |
  |      |      + -- Сырье 1
 
  |      |      |
  |      |      + -- Сырье 2
 
  |      |      
  |      + -- Полуфабрикат 2      
 
  |      |      |
  |      |      + -- Сырье 3
 
  |      |      |
  |      |      + -- Сырье 4
 
  |      |      
  |      + -- СЫрье 7      
 
  |      |      
  |      + -- Изделие 2
 
  |             
  +  -- Рецепт 2             
 
  |      |      
  |      + -- Полуфабрикат 1
 
  |      |      |
  |      |      + -- Сырье 1
 
  |      |      |
  |      |      + -- Сырье 2
 
  |      |      
  |      + -- Полуфабрикат 4
 
  |             |
  |             + -- Сырье 3
 
  |             |
  |             + -- Сырье 7
 
  и т.д.


В итоге имеем следующие таблицы:

RAW_MAT (ID, NAME) - Сырье

PREP_MAT (ID, NAME) - Полуфабрикат

PREP_MAT_RAW (PREP_MAT_ID, RAW_MAT_ID) - Состав полуфабриката


RECIPE(ID, NAME) - Рецепт

RECIPE_PREP_MAT(RECIPE_ID, PREP_MAT_ID, RAW_MAT_ID, PROD_ID) - Состав рецепта


PRODUCTION (ID, NAME) - Изделие

PRODUCT_RECIPE (PROD_ID, RECIPE_ID) - Рецепты приготовления
...
Рейтинг: 0 / 0
01.05.2003, 08:46
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152323
Фотография Andrew Campball
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrew Campball
Участник
Давайте разберемся с таким раскладом:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
Изделие  1 
  |
  + -- Рецепт 1
 
  |      |
  |      + -- Полуфабрикат 1
 
  |      |      |
  |      |      + -- Сырье 1
 
  |      |      |
  |      |      + -- Сырье 2
 
  |      |      
  |      + -- Полуфабрикат 2      
 
  |      |      |
  |      |      + -- Сырье 3
 
  |      |      |
  |      |      + -- Сырье 4
 
  |      |      
  |      + -- СЫрье 7      
 
  |      |      
  |      + -- Изделие 2
 
  |             
  +  -- Рецепт 2             
 
  |      |      
  |      + -- Полуфабрикат 1
 
  |      |      |
  |      |      + -- Сырье 1
 
  |      |      |
  |      |      + -- Сырье 2
 
  |      |      
  |      + -- Полуфабрикат 4
 
  |             |
  |             + -- Сырье 3
 
  |             |
  |             + -- Сырье 7
 
  и т.д.


В итоге имеем следующие таблицы:

RAW_MAT (ID, NAME) - Сырье

PREP_MAT (ID, NAME) - Полуфабрикат

PREP_MAT_RAW (PREP_MAT_ID, RAW_MAT_ID) - Состав полуфабриката


RECIPE(ID, NAME) - Рецепт

RECIPE_PREP_MAT(RECIPE_ID, PREP_MAT_ID, RAW_MAT_ID, PROD_ID) - Состав рецепта


PRODUCTION (ID, NAME) - Изделие

PRODUCT_RECIPE (PROD_ID, RECIPE_ID) - Рецепты приготовления
...
Рейтинг: 0 / 0
01.05.2003, 08:46
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152331
Репликант
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Репликант
Участник
2 kondi:
Т.е. рецептура изделия может содержать как сырье (и полуфабрикаты), так и изделия, например для рецептур наборов изделий (т.е. набор являясь изделием сам состоит из готовых изделий) Поле ID_RP_Comp в зависимости от значения поля Flag_RP_Comp ссылается на ID_Raw из Raw, или на ID_Prod из Prod. Аналогично рецептура полуфабриката может включать готовое изделие

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

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

...это как "рецептура торта содержит такой-то торт". Не странно ли звучит? Если странно, то у вас в физической модели должны быть механизмы (триггеры), к-рые подобные связи предотвращали бы. Опять же если рецептура может содержать более одной рецептур, то это обратная связь через ассоциативную сущность

Хочу при переходе на SQL Server предоставить эти заботы самой СУБД.

Подход конечно правильный, но он далеко не полный, поэтому кроме автоматической поддержки ссылочной и целостности таблиц следует задаться еще и следующими вопросами:
а) Является ли ваша модель данных конечной? Если нет, то как она в будущем может/должна быть расширяема - эти ответы помогут определить конечную или промежуточную логическую модель.
б) Какие запросы будут? - эти ответы и а) помогут определить физическую модель и необходимую степень нормализации

Выхода вижу два
1) слить все в 2 таблицы
Таблица RP – изделия, сырье и полуфабрикаты (ID_RP, Name_RP, Flag_RP)
Таблица RcRP – рецептуры (ID_RP, ID_RP_Comp (FK) , Weight)

Для удобства работы сделать представления для RP используя поле Flag_RP, чтобы готовые изделия, полуфабликаты и сырье оказались в разных представлениях.

Чем тогда сырье от изделия отличается или от полуфабриката кроме своего имени? Приходим к тому, что с самого сначала следовало бы определить и показать хотя бы краткий словарь ваших предметных терминов (можно даже с небольшими примерами рецептур), а то народ мучается в догадках, вон например Cat2 уже начал использовать новый термин - "ингридиент".
Далее: у вас в подходе 1) получается, что если RcRP.ID_RP - ключ, то рецептура может состоять только из 1-го изделия/сырья/полуфабриката, но по-вашему же это не так: рецептура изделия может содержать как сырье (и полуфабрикаты), так и изделия,...

2) изменить структуру таблиц с рецептурами
Таблица RcProd – рецептуры продуктов (ID_Prod, ID_Raw_Comp, ID_Prod_Comp, Weight)
Таблица RcRaw – рецептуры полуфабрикатов (ID_Raw, ID_Raw_Comp, ID_Prod_Comp, Weight)

Тогда ID_Raw_Comp будет ссылаться на ID_Raw из Raw, а ID_Prod_Comp на ID_Prod из Prod, конечно одно из этих полей должно быть равно NULL

Ну здесь вообще у вас какая-то каша получается - перекрестные ссылки, т.е не только родитель должен знать из кого он состоит, но и детки в кого они входят что ли? Вы вообще с реляционной теорией знакомы или под Clipper-ом это не играет никакого значения? Зря вы думаете (если думаете), что MSSQL с его средствами поддержки целостности позволяет забить на это дело :)
...
Рейтинг: 0 / 0
01.05.2003, 10:20
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152419
kondi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kondi
Гость
Верно, Andrew Campball, вы заметили и ввели таблицу рецепт, но для упрощения понимания проблемы давайте примем что изделия и полуфабрикаты могут иметь только одну рецептуру и поэтому таблицу «Recipe» безжалостно выкидываем.

А теперь почитайте что по поводу вашей таблицы
RECIPE_PREP_MAT(RECIPE_ID, PREP_MAT_ID, RAW_MAT_ID, PROD_ID) - Состав рецепта

пишет Репликант:
Ну здесь вообще у вас какая-то каша получается - перекрестные ссылки, т.е не только родитель должен знать из кого он состоит, но и детки в кого они входят что ли? Вы вообще с реляционной теорией знакомы или под Clipper-ом это не играет никакого значения? Зря вы думаете (если думаете), что MSSQL с его средствами поддержки целостности позволяет забить на это дело :)

Вот так он нас раскритиковал, даже мысли наши прочитал, IMHO не поставил – уверен на все 100 что я халявщик )) А я просто не хочу чтобы SQL у меня халявил.

А Вы чем там в Вологде занимаетесь, не продуктами ли c полуфабрикатами?

to Cat2:

Ингредиент подходящая сущность, но и его выбрасываем за ненадобностью т.к. в качестве ингредиента может выступать все (и сырье, и полуфабрикат, и изделие)
Рецептура крошки = рецептуре изделия
Глубина вложенности не ограничена.
От циклов не избавится по причине использования возвратных отходов.
Еще один пример: Вафли состоят из вафельного листа и начинки, в начинку идет крошка самих вафель получающаяся когда вафли (большой пласт состоящий из вафельных листов размером 100 на 100 и начинки) разрезают на мааа-ленькие вафли размером 1 на 1.

to Репликант

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

Что касается «торта в торте» - и такое возможно, но я кажется довольно понятный пример привел с крошкой.

>Далее: у вас в подходе 1) получается, что если RcRP.ID_RP - ключ, то рецептура может состоять
>только из 1-го изделия/сырья/полуфабриката, но по-вашему же это не так: рецептура изделия
>может содержать как сырье (и полуфабрикаты), так и изделия,...

Я что где-то писал что RcRP.ID_RP это ПЕРВИЧНЫЙ ключ? А что ключи бывают только УНИКАЛЬНЫМИ? Да-ааа, с такими знаниями реляционной теории, SQL точно не поможет, а в Clipper-е вообще утонуть можно

Репликант, за мной не заржавеет ;)

Сырье, полуфабрикаты и изделия имеют как одинаковые, так и разные атрибуты. Поэтому можно сделать 3 таблицы, можно одну, а можно, как это было сделано мной в 1990-м или 1991 году, создать 2 таблицы, поскольку между сырьем и полуфабрикатами общего больше.
...
Рейтинг: 0 / 0
01.05.2003, 17:19
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152446
Фотография Циничный Кот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Циничный Кот
Участник
Маленько в сторону от темы. Объясните, если несложно, вот этот момент:

А что ключи бывают только УНИКАЛЬНЫМИ?

Что такое НЕ УНИКАЛЬНЫЙ ключ???...
...
Рейтинг: 0 / 0
01.05.2003, 20:44
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152460
Фотография Andrew Campball
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrew Campball
Участник
2 Репликант
Ну здесь вообще у вас какая-то каша получается - перекрестные ссылки, т.е не только родитель должен знать из кого он состоит, но и детки в кого они входят что ли? Вы вообще с реляционной теорией знакомы ...
Странно? Можно пояснить смысл Вашей фразы и в общих чертах в чем противоречие с теорией ?

2 kondi
А Вы чем там в Вологде занимаетесь, не продуктами ли c полуфабрикатами?
Абсолютно противоположным :-) Абсолютно не пригодным в пищу

Рецептура крошки = рецептуре изделия
Глубина вложенности не ограничена.
До молекул не раскладываете? :-))) Всегда должно быть ограничение.
Даже с той же крошкой: не думаю что стоит ее расскладывать лучше принять ее как сырье.

Даже если рассматривать с такой точки зрения:
Для производства вафельного листа нужно: мука - 1 кг, яйцо - 10 шт.
Для производства крошки что нужно и сколько ?
...
Рейтинг: 0 / 0
01.05.2003, 22:35
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152543
Репликант
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Репликант
Участник
2 kondi: \r
Вот так он нас раскритиковал, даже мысли наши прочитал, IMHO не поставил – уверен на все 100 что я халявщик )) А я просто не хочу чтобы SQL у меня халявил. \r
\r
Ну почему же халявщик? Может вы заблуждающийся или неграмотный (в хорошем смысле этого слова). :)\r
И прежде чем подтрунивать надо мной по поводу пропущенного "IMHO" вы бы все-таки обосновали, что же я вам такого неправильного насоветовал. Ведь посоветовал-то я вам самые очевидные и правильные с инженерной точки зрения вещи, к-рые знает любой приличный разработчик БД т.е к-рый...\r
а) знаком хоть с одним нормальным структурным подходом (SDLC, SASD и тд) к разработке БД\r
- там везде вначале стоят спецификации требований и словарь, из к-рых все остальное\r
и получается. Вы же пытаетесь получить помощь (т.е вы виртуально привлекаете их\r
в свой проект) даже не познаковив людей нормально со свой проблемой, к-рая является очень даже\r
предметно-специфической . Это не только неграмотно (поскольку вы тут конкурс на лучшую\r
идею не объявляли), но неуважительно заставлять работать людей вхолостую:\r
\r
Верно, Andrew Campball, вы заметили и ввели таблицу рецепт,\r
но для упрощения понимания проблемы давайте примем что изделия и полуфабрикаты могут\r
иметь только одну рецептуру и поэтому таблицу «Recipe» безжалостно выкидываем. \r
\r
to Cat2: Ингредиент подходящая сущность, но и его выбрасываем\r
за ненадобностью т.к. в качестве ингредиента может выступать все (и сырье,\r
и полуфабрикат, и изделие) \r
\r
б) знаком с реляционной теорией Кодда - вы все-таки пытаетесь свою БД запускать под "реляционой" СУБД (MSSQL).\r
Хотя конечно под любой РСУБД можно реализовывать любые нереляционные фантазии, но уже лучше\r
тогда сразу на объектную СУБД перейти поскольку реляционность СУБД именно означает, что\r
она создана и заточена под хранение и операции с реляционными объектами\r
\r
Ну не в форуме же обсуждать полную концепт. модель и словарь реальной задачи, я старался привести минимум информации необходимый для понимания проблемы. \r
\r
Именно так! Не обязательно всю, можно какую-то ее часть, но только ограниченную и желательно более или менее самодостаточную. Иначе все ваши помощники просто будут барахтаться в бассейне как старые толстые тетки, а не плавать\r
\r
Я что где-то писал что RcRP.ID_RP это ПЕРВИЧНЫЙ ключ? А что ключи бывают только УНИКАЛЬНЫМИ? Да-ааа, с такими знаниями реляционной теории, SQL точно не поможет, а в Clipper-е вообще утонуть можно \r
\r
Ваша теория, с к-рой вы под Clipper базы создаете, какая угодно - псевдо-, квази- или околореляционная, но только не реляционная: "А что ключи бывают только УНИКАЛЬНЫМИ?" :)\r
\r
2 Andrew Campball :\r
Странно? Можно пояснить смысл Вашей фразы и в общих чертах в чем противоречие с теорией ? \r
\r
1) Если у "kondi" ключи неуникальные или какое-то значение составляющего его атрибута неопределено (NULL), то либо это теория уже нереляционная либо ее 1-е требование - удовлетворение таблицей (если в терминах физической модели) 1NF нарушено и это уже автоматически не нормализованная таблица\r
\r
Таблица RcProd – рецептуры продуктов (ID_Prod, ID_Raw_Comp (FK1) , ID_Prod_Comp (FK2) , Weight)\r
Таблица RcRaw – рецептуры полуфабрикатов (ID_Raw, ID_Raw_Comp (FK1) , ID_Prod_Comp (FK2) , Weight)\r
\r
2) "kondi" пытается хранить избыточную информацию об отношениях отношениях/связях, т.е не только родитель ссылается на дите, но и дите на родителя - хотя должно быть достаточно только одного: <parent> -> <child> (или <parent> <- <child>) опять же согласно реляционной теории. Далее: в его концептуальной модели даже не указывается кто в какой роли выступает в отношении, т.е. тип отношений вообще не свойственный реляционной теории
...
Рейтинг: 0 / 0
02.05.2003, 13:19
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152554
kondi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kondi
Гость
2 Циничный кот

Если что не понятно не по теме, делайте новый топик «Что такое НЕ УНИКАЛЬНЫЙ ключ???...» надеюсь там вам помогут ))))))))

FK – этой аббревиатуры от меня Вам будет достаточно? ;)


2 Andrew Campball

От циклов не избавится и вот почему:
Например нужно рассчитать влажность изделия, откуда брать влажность крошки которая равна влажности готового изделия?
(допустим алгоритм элементарен – имея влажность компонентов рецептуры рассчитываем влажность смеси компонентов это и будет влажность готового изделия)

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

Но пример с влажностью не единственная причина почему возвратные отходы нельзя приравнять к сырью.


2 all

Как-то отдаляемся мы от темы.
...
Рейтинг: 0 / 0
02.05.2003, 14:02
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152602
kondi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kondi
Гость
2 Циничный кот
2 Репликант

Ребята у меня книжка 1998 года, там написано Foreign Key, слово Foreign я знаю как перевести - «внешний» - правильно? Я не ошибся? А вот слово Key помогите пожалуйста перевести правильно, я кажется его неправильно перевожу. Наверно у вас обоих оно переводится одинаково, но как то по другому чем у меня?

2 Репликант

Сначала я у вас халявщиком был, потом заблуждающимся или неграмотным, потом снова неграмотным и неуважительным. Мне кажется Вам пора заглянуть в зеркало.



Еще раз попробую объяснить варианты

Вариант 1

Таблица RP – изделия, сырье и полуфабрикаты (ID_RP (PK), Name_RP, Flag_RP)
Таблица RcRP – рецептуры (ID_RP(FK), ID_RP_Comp(FK), Weight) и для ярых реляционщиков составной (PK)(ID_RP, ID_RP_Comp)

Вариант 2

Таблица Prod – изделия (ID_Prod(PK), Name_Prod)
Таблица Raw – сырье и полуфабрикаты (ID_Raw(PK), Name_Raw)
Таблица RcProd – рецептуры продуктов (ID_Prod(FK), ID_Raw_Comp(FK), ID_Prod_Comp(FK), Weight) вот здесь (PK)(ID_Prod, ID_Raw_Comp, ID_Prod_Comp) не пойдет из-за присутствия NULL, хотя уникальный FK (что почти эквивалентно РК) проходит.
Таблица RcRaw – рецептуры полуфабрикатов (ID_Raw(FK), ID_Raw_Comp(FK), ID_Prod_Comp(FK), Weight) аналогично.


2 Репликант
Помните в фильме «Цыган»: «сейчас вам скажут волшебное слово… …КРЫШКА»
Вот и я Вам подсказываю: UNION
...
Рейтинг: 0 / 0
02.05.2003, 19:26
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152657
Репликант
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Репликант
Участник
2 kondi:
Как-то отдаляемся мы от темы.

Постановку задачи следует формулировать грамотно, тогда и не будет отдалений!

Ребята у меня книжка 1998 года, там написано Foreign Key, слово Foreign я знаю как перевести - «внешний» - правильно? Я не ошибся? А вот слово Key помогите пожалуйста перевести правильно, я кажется его неправильно перевожу. Наверно у вас обоих оно переводится одинаково, но как то по другому чем у меня?

Только передергивать не надо, что якобы кто-то тут переводит неправильно. Словосочетание "Foreign Key" вы запостили только в пятницу 2-го мая. Что ж вы так поздно вспомнили о нем или считаете что здесь все телепаты или должны догадываться? :(

Сначала я у вас халявщиком был, потом заблуждающимся или неграмотным, потом снова неграмотным и неуважительным. Мне кажется Вам пора заглянуть в зеркало.

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

Еще раз попробую объяснить варианты...

Сразу трудно было что ли добавить аббревиатуры "PK" и "FK"?

Вариант 1

Таблица RP – изделия, сырье и полуфабрикаты (ID_RP (PK), Name_RP, Flag_RP)
Таблица RcRP – рецептуры (ID_RP(FK), ID_RP_Comp(FK), Weight)
и для ярых реляционщиков составной (PK)(ID_RP, ID_RP_Comp)

Если это утверждение в силе:
Поле ID_RP_Comp в зависимости от значения поля Flag_RP_Comp ссылается на ID_Raw из Raw, или на ID_Prod из Prod. Аналогично рецептура полуфабриката может включать готовое изделие.

то это получается "тернарный" тип отношений т.к в нем учавствуют 3 таблицы: RcRP (дочерняя), Prod (родитель 1), Raw (родитель 2). Это плохо или хорошо и можно ли без этого типа обойтись? Также: почему флаг, к-рый определяет кто родитель у записи RcRP находится в другой таблице?

Вариант 2

Таблица Prod – изделия (ID_Prod(PK), Name_Prod)
Таблица Raw – сырье и полуфабрикаты (ID_Raw(PK), Name_Raw)

Таблица RcProd – рецептуры продуктов (ID_Prod(FK), ID_Raw_Comp(FK), ID_Prod_Comp(FK), Weight)
вот здесь (PK)(ID_Prod, ID_Raw_Comp, ID_Prod_Comp) не пойдет из-за присутствия NULL, хотя уникальный FK (что почти эквивалентно РК) проходит.
Таблица RcRaw – рецептуры полуфабрикатов (ID_Raw(FK), ID_Raw_Comp(FK), ID_Prod_Comp(FK), Weight) аналогично.

В этом варианте флагов типа RP.Flag_RP нет, поэтому закономерно возникает вопрос:
RcProd.ID_Raw_Comp(FK) и RcProd.ID_Prod_Comp(FK) - это ссылки на кого, аналогично и RcRaw.ID_Raw_Comp(FK) и RcRaw.ID_Prod_Comp(FK)?

Помните в фильме «Цыган»: «сейчас вам скажут волшебное слово… …КРЫШКА»
Вот и я Вам подсказываю: UNION

Нет, фильм не помню т.к давно его смотрел. Причем здесь "КРЫШКА", а также UNION? Объясните, пожалуйста, если нетрудно
...
Рейтинг: 0 / 0
03.05.2003, 09:00
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152777
kondi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kondi
Гость
OFF:

Чего же Вы так на жизнь обижены - желчь в каждом посте. Это конечно ваши проблемы, но уровень серотонина нужно поднимать.

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

>Ваша теория, с к-рой вы под Clipper базы создаете, какая угодно - псевдо-, квази- или
>околореляционная, но только не реляционная: "А что ключи бывают только УНИКАЛЬНЫМИ?" :)

Ну признайтесь, написали глупость, да еще какую, так и быть я Вас прощаю (и никому не расскажу, что в форуме по проектированию баз данных один гурец нервно хихикая на пост «А что ключи бывают только УНИКАЛЬНЫМИ?» ответил «Ваша теория какая угодно - но только не реляционная»), повторяю – я Вас прощаю, но больше без фельдфебельских замашек, диалог только по теме.

По теме:
Где Вы увидели в первом варианте поле ID_RP_Comp, а где таблицы Raw и Prod. То что Вы процитировали относилось к исходной структуре таблиц - смотрим самый первый пост, ну объясните мне почему или зачем Вы это притянули к первому варианту новой структуры.

Flag_RP это поле которое позволяет определить чем является запись в этой общей таблице – сырьем, полуфабрикатом или изделием.

По поводу второго варианта
Ответ:
RcProd.ID_Raw_Comp(FK) -> Raw.ID_Raw(PK)
RcProd.ID_Prod_Comp(FK) -> Prod.ID_Prod(PK)
RcRaw.ID_Raw_Comp(FK) -> Raw.ID_Raw(PK)
RcRaw.ID_Prod_Comp(FK) -> Prod.ID_Prod(PK)

Репликатор давайте вместе посмеемся – ответ на этот ваш вопрос был в первом посте:

> Тогда ID_Raw_Comp будет ссылаться на ID_Raw из Raw, а ID_Prod_Comp на ID_Prod из Prod,

Мне уже смешно, а Вам?

Про фильм точно не врете? Как звали главного героя? У мамы, чур не спрашивать )))
...
Рейтинг: 0 / 0
04.05.2003, 00:25
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152898
Replicant
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Replicant
Гость
2 kondi:
Чего же Вы так на жизнь обижены - желчь в каждом посте. Это конечно ваши проблемы, но уровень серотонина нужно поднимать.

Где это вы "желчь" нашли!? Приведите соответствующую цитату. С чего вы также взяли, что у меня уровень серотонина низкий? У меня признаков депрессии как раз не наблюдается - в темных душных помещениях не сижу и в одну точку маленького мониторчика целыми днями с серым лицом не смотрю как некоторые разработчики. Так что свои псевдоврачебные гипотезы оставьте для своих близких, а то я ведь тоже могу сказать, что у вас уровень тестостерона низкий и у вас помимо детского фальцеватого голоска еще и наблюдается отсталость в физическом развитии рук поскольку вы всегда что-то пишете, но не дописываете важные вещи

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

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

Ну признайтесь, написали глупость, да еще какую, так и быть я Вас прощаю (и никому не расскажу, что в форуме по проектированию баз данных один гурец нервно хихикая на пост «А что ключи бывают только УНИКАЛЬНЫМИ?» ответил «Ваша теория какая угодно - но только не реляционная»), повторяю – я Вас прощаю, но больше без фельдфебельских замашек, диалог только по теме.

Похоже вы страдаете весенними галлюцинациями: почему вы решили что я нервно хихикал на ваш пост? Если вы читаете чужие посты невнимательно, то о чем с вами вообще разговаривать - повторюсь: из ваших "объяснений" было неясно какой именно ключ (первичный или внешний), а если у вас отношение идентифицирующее и оба внешних ключа составляют первичный, то так и надо писать, что RcRP.ID_RP - это тоже внешний ключ потому что исходя только из его имени и ваших объяснений про предметные связи не понятно первичный он у вас или внешний, являющийся его частью. Так что сначала простите себя за свою лень и сумбурность в изложении своей проблемы

По теме:
Где Вы увидели в первом варианте поле ID_RP_Comp, а где таблицы Raw и Prod. То что Вы процитировали относилось к исходной структуре таблиц - смотрим самый первый пост, ну объясните мне почему или зачем Вы это притянули к первому варианту новой структуры.

С Raw и Prod все ясно - притянул зря, по поводу поля ID_RP_Comp - исходя из вашего же поста (Дата: 2 май 03, 19:26):
Еще раз попробую объяснить варианты
Вариант 1

Таблица RP – изделия, сырье и полуфабрикаты (ID_RP (PK), Name_RP, Flag_RP)
Таблица RcRP – рецептуры (ID_RP(FK), ID_RP_Comp(FK), Weight) и для ярых реляционщиков составной (PK)(ID_RP, ID_RP_Comp)
Flag_RP это поле которое позволяет определить чем является запись в этой общей таблице – сырьем, полуфабрикатом или изделием.

Этот вариант не без недостатков: т.к ограничения типа Not Null, Check (), специфические для конкретного изделия/сырья/полуфабриката нельзя будет использовать для RP, т.е придется либо делать логику в ХП, к-рая например при вставке проверяет флаг Flag_RP т.е что за объект изделие/сырье/полуфабрикат вставляется и в зависмости от этого разрешать либо выкручиваться с видами, т.е создавать для каждого конкретного изделия/сырья/полуфабриката. Да вы и сами до этого почти дошли:

Сырье, полуфабрикаты и изделия имеют как одинаковые, так и разные атрибуты. Поэтому можно сделать 3 таблицы, можно одну, а можно, как это было сделано мной в 1990-м или 1991 году, создать 2 таблицы, поскольку между сырьем и полуфабрикатами общего больше.

По поводу второго варианта
Ответ:
RcProd.ID_Raw_Comp(FK) -> Raw.ID_Raw(PK)
RcProd.ID_Prod_Comp(FK) -> Prod.ID_Prod(PK)
RcRaw.ID_Raw_Comp(FK) -> Raw.ID_Raw(PK)
RcRaw.ID_Prod_Comp(FK) -> Prod.ID_Prod(PK)

Из этого следует, что рецептура продукта (RcProd) может состоять только из 1 сырья/полуфабриката (Raw) и 1 изделия (Prod), а рецептура полуфабриката (RcRaw) может состоять только из 1 сырья/полуфабриката (Raw) и 1 изделия (Prod). Звучит как тавтология и достаточно ограниченная модель, но если она подходит для вашей предметной области, то ОК. Однако можно сделать чтобы любая рецептура была уникально идентифицирована атомарным PK (это же удобно для использования его в виде числового артикула/ИД на предприятии) и состояла бы из любого кол-ва полуфабриактов/изделий. Единственное что тогда надо будет определять пользователю это: а) рецептуры, б) изделия/полуфабрикаты (крошка, вафельные листы и тд) и в) исходные неделимые ингридиенты (вода, сахар, мука и тд) из к-рых состоят а) и б)

У вас кстати используется 2 термина "изделие" и "продукт":
Имеем: изделия, сырье, полуфабрикаты и рецептуры продуктов и изделий

Как было сделано мной на Clipper-е
Таблица Prod – изделия (поля: ID_Prod, Name_Prod)
Таблица Raw – сырье и полуфабрикаты (ID_Raw, Name_Raw)
Таблица RcProd – рецептуры изделий (ID_Prod, Flag_RP_Comp, ID_RP_Comp, Weight)
Таблица RcRaw – рецептуры полуфабрикатов (ID_Raw, Flag_RP_Comp, ID_RP_Comp, Weight)
....
2) изменить структуру таблиц с рецептурами
Таблица RcProd – рецептуры продуктов (ID_Prod, ID_Raw_Comp, ID_Prod_Comp, Weight)
Таблица RcRaw – рецептуры полуфабрикатов (ID_Raw, ID_Raw_Comp, ID_Prod_Comp, Weight
это одно и тоже или нет?

Репликатор давайте вместе посмеемся – ответ на этот ваш вопрос был в первом посте:

А это уже непрекрытое хамство - намеренное искажение ника :(

Про фильм точно не врете? Как звали главного героя? У мамы, чур не спрашивать

Не вру, но я вам не первый вопрос уже задаю, но вы либо не отвечаете либо отвечаете вопросом и несете какую-то лирическую чушь про маму - это явно указывает на ваше невежество и несерьезность
...
Рейтинг: 0 / 0
04.05.2003, 18:23
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32152928
kondi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kondi
Гость
OFF

Кто Вам мешал уточнить о каком ключе идет речь, прежде чем сбрехнуть что это не реляционная теория.

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

>это одно и тоже или нет?
Это нет, а зачем Вы передернули, вместо моей цитаты из первого поста
>Тогда ID_Raw_Comp будет ссылаться на ID_Raw из Raw, а ID_Prod_Comp на ID_Prod из Prod,
вставили другую:
>2) изменить структуру таблиц с рецептурами
>Таблица RcProd – рецептуры продуктов (ID_Prod, ID_Raw_Comp, ID_Prod_Comp, Weight)
>Таблица RcRaw – рецептуры полуфабрикатов (ID_Raw, ID_Raw_Comp, ID_Prod_Comp, Weight

Про ник, это ненамеренное искажение, а наверно это моя
>отсталость в физическом развитии рук :(
так сказалась на вашем нике.

По теме

>У вас кстати используется 2 термина "изделие" и "продукт"

Конечно согласен в принципе что термин должен быть один, в реальной базе это «продукт», а для объяснения задачи лучше использовать термин «изделие», но для понимания особенности задания рецептур (изделие в рецептуру изделия) пришлось и «продукт» упомянуть. Никто из участников топика не воспринял это как разные сущности, даже >вы и сами до этого почти дошли.


1-й вариант
По поводу ID_RP_Comp, ошибся, имел ввиду Flag_RP_Comp.

2-й вариант, да действительно, нужно новое поле в качестве атомарного PK, а так ли нужен здесь PK? Это вопрос всем кроме Репликанта, его ответ я знаю, и не спорю с ним.

Репликант давайте ближе к сути проблемы, теперь Вам постановка ясна?

Про UNION – при правильной (реляционной) структуре таблиц без него не обойтись. Что скажете?
...
Рейтинг: 0 / 0
04.05.2003, 23:29
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32153127
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jinn
Гость
Ну вот от решения технической проблемы скатились к мерянию девайсами :)
А все не так уж сложно.

Первая таблица - Наименования. Структура - ниже.
Name_ID [PK]
Name_Val
Вторая таблица - Дерево
Tree_ID [PK]
Owner_ID (указатель на Tree_ID) [FK]
Name_ID (указатель на Name_ID в таблице Наименования)
Таким образом одно наименование может входить в разные ветви дерева, точнее разные ветви дерева могут ссылаться на одно наименование.
Для удобства работы можно еще создать таблицу параметров:
Param_ID [PK]
Owner_ID (указатель на Tree_ID или Name_ID)
Name_ID (указатель на Name_ID, имя параметра)
Param_Val (значение параметра, тип по потребности)
В этой таблице можно хранить как рецептуру изделия, так и характеристики сырья, да и вообще любые свойства. В случае привязки к наименованию - общие характеристики, в случае привязки к дереву - конретные по данной ветви дерева. Идентификаторы сквозные.
На Oracle все это легко проходит.
...
Рейтинг: 0 / 0
05.05.2003, 11:30
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32153329
Репликант
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Репликант
Участник
2 kondi:
Кто Вам мешал уточнить о каком ключе идет речь, прежде чем сбрехнуть что это не реляционная теория.

Вы же сами пришли с вопросом и еще хотите чтобы люди у вас выпытывали кто есть кто в вашей задаче?! Сразу если бы написали, что он внешний и не было бы никаких бурных замечаний про неуникальность "первичных" ключей

>это одно и тоже или нет?
Это нет, а зачем Вы передернули, вместо моей цитаты из первого поста

Не передергивал, я просто привел 2 источника ("..." - граница раздела), где используются 2 термина "изделие" (было раньше на Clipper) и "продукт" (новый вариант)

Конечно согласен в принципе что термин должен быть один, в реальной базе это «продукт», а для объяснения задачи лучше использовать термин «изделие», но для понимания особенности задания рецептур (изделие в рецептуру изделия) пришлось и «продукт» упомянуть. Никто из участников топика не воспринял это как разные сущности, даже >вы и сами до этого почти дошли.

Это как термин "масло сливочное" лучше чем "сливочное масло". Просто еще раз хотелось убедиться, что за этой "разницей" в терминах не кроется еще что-то

Репликант давайте ближе к сути проблемы, теперь Вам постановка ясна?

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

Про UNION – при правильной (реляционной) структуре таблиц без него не обойтись. Что скажете?

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

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

А это зачем, если уникальность наименования продукта/полуфабриаката/рецептуры не обязательна?

Для удобства работы можно еще создать таблицу параметров:
Param_ID [PK]
Owner_ID (указатель на Tree_ID или Name_ID)
Name_ID (указатель на Name_ID, имя параметра)
Param_Val (значение параметра, тип по потребности)
В этой таблице можно хранить как рецептуру изделия, так и характеристики сырья, да и вообще любые свойства.

Тип по потребности - это sql_variant что ли?
...
Рейтинг: 0 / 0
05.05.2003, 13:52
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32153393
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jinn
Гость
2 Jinn:
Таким образом одно наименование может входить в разные ветви дерева, точнее разные ветви дерева могут ссылаться на одно наименование.

А это зачем, если уникальность наименования продукта/полуфабриаката/рецептуры не обязательна?

Затем,чтобы не плодить лишней информации. А уникальность потом все равно понадобится. Чаще всего так и бывает.
Я это делал для машиностроения. Очень удобно когда требуется узнать назначение узла/сборочной единицы, поскольку один и тот же узел может быть и запчастью и готовым изделием и входить еще черт знает куда. А тут - одним запросом.

Для удобства работы можно еще создать таблицу параметров:
Param_ID [PK]
Owner_ID (указатель на Tree_ID или Name_ID)
Name_ID (указатель на Name_ID, имя параметра)
Param_Val (значение параметра, тип по потребности)
В этой таблице можно хранить как рецептуру изделия, так и характеристики сырья, да и вообще любые свойства.

Тип по потребности - это sql_variant что ли?

Любой, какой удобней использовать. Можно и собственный тип, содержащий необходимые для работы поля.
...
Рейтинг: 0 / 0
05.05.2003, 14:17
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32153495
Репликант
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Репликант
Участник
2 Jinn: \r
Затем,чтобы не плодить лишней информации. А уникальность потом все равно понадобится. Чаще всего так и бывает. \r
Я это делал для машиностроения. Очень удобно когда требуется узнать назначение узла/сборочной единицы, поскольку один и тот же узел может быть и запчастью и готовым изделием и входить еще черт знает куда. А тут - одним запросом. \r
\r
Ёмоё, какая тяга к нормализации (я даже не врубаюсь, какая это форма будет?) можно подумать у "kondi" будет мильон наименований и число джойнов возрастет на 1 в запросах где будут нужны "Наименования"\r
\r
Любой, какой удобней использовать. Можно и собственный тип, содержащий необходимые для работы поля. \r
\r
Это в Oracle что ли так можно - тип, состоящий из полей ? У "kondi" - MSSQL
...
Рейтинг: 0 / 0
05.05.2003, 15:18
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32153573
Фотография Циничный Кот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Циничный Кот
Участник
2 kondi\r
\r
Приглашаю СЮДА, там разберемся, откуда что берется и куда потом суется.
...
Рейтинг: 0 / 0
05.05.2003, 16:18
| Ответить | Цитировать | Написать  
одно поле -> две таблицы. Что подскажет опыт?
    #32153583
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jinn
Гость
Репликант
Ёмоё, какая тяга к нормализации (я даже не врубаюсь, какая это форма будет?) можно подумать у kondi будет мильон наименований и число джойнов возрастет на 1 в запросах где будут нужны "Наименования"

Никакой тяги - обыкновенная систематизация хранимых данных. Формы нормализации - понятие условное, я бы даже сказал утрированное. А вот то, что в дальнейшем потребуется поиск по контексту наименования - я мало сомневаюсь. Данные хранятся для использования, а не для красоты :)

Любой, какой удобней использовать. Можно и собственный тип, содержащий необходимые для работы поля.

Это в Oracle что ли так можно - тип, состоящий из полей? У kondi - MSSQL

Ну, я их особо и не использовал, просто обявлял символьный тип, а потом приводил в нужный.
...
Рейтинг: 0 / 0
05.05.2003, 16:24
| Ответить | Цитировать | Написать  
25 сообщений из 35, страница 1 из 2
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / одно поле -> две таблицы. Что подскажет опыт?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=32152657&tid=1546963]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 185ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 63ms
get tp. blocked users:
 2ms
others: 247ms
total:  540ms
созд. / загр.: 540ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]