powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование без избыточности
25 сообщений из 63, страница 1 из 3
Проектирование без избыточности
    #39395637
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте.

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

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

Посоветуйте что-нибудь, а то я запуталась. Что выбрать? Я хочу сделать по правилам.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395673
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelЗдравствуйте.

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

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

Посоветуйте что-нибудь, а то я запуталась. Что выбрать? Я хочу сделать по правилам.

Если у Вас на одном действии может быть несколько документов, а один документ относиться к нескольким действиям - это, очевидно, отношение "многие ко многим".
Достаточно странно, что добавление одной связующей таблицы превращает запросы в "безумные"
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395679
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскин, спасибо за ответ.
Понимаете, на самом деле получается гораздо больше таблиц в запросе! Вовсе не две!
1. Таблица "Действия".
2. Таблица "Ассоциированные документы", где действиям присвоены ид документов.
3. Таблица "Документы" с полями серии, номера, даты начала и окончания, выдавшей организации, подписавшего человека.
4. Таблица "Юрлица", связанная с таблицей "Документы" по ид_юрлица" - для получения в запросе наименования юрлица, выдавшего документ.
5. Таблица "Физлица", связанная с таблицей "Документы" по ид_физлица" - для получения в запросе наименования физлица, подписавшего документ.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395685
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelКот Матроскин, спасибо за ответ.
Понимаете, на самом деле получается гораздо больше таблиц в запросе! Вовсе не две!

Это понятно, я имел в виду -становится на одну таблицу больше.
В одном случае у Вас 4 таблицы, в другом 5 - такая ли большая разница?
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395733
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurel может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении".Если документов может быть только два и никогда три или больше (даже в военное время и по особому распоряжению) то ваш подход с двумя document_id вполне нормальный.
Повесьте check на таблицу, чтобы исключить ситауации когда основной document_id пустой, а дополнительный нет.
Добавление третьего document_id превращает check в очень громоздкий, а четвертый в полный кошмар.

OkeTurel Я ненавижу избыточность и стараюсь строить базы строго из нужных полейЭто пройдет с годами
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395767
аля1ц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
OkeTurel,

... Я хочу сделать по правилам.


...правила на то и существуют чтоб их нарушать....)


избыточность - если не безумная

может быть полезна



.OkeTure..Я решила было плюнуть
и вообще не выносить документы в отдельную таблицу,
а сделать для ИД документа 2 поля в основных таблицах....


так можно и в уважаемый Ексель вернуться...))
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395790
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelКот Матроскин, спасибо за ответ.
Понимаете, на самом деле получается гораздо больше таблиц в запросе! Вовсе не две!
1. Таблица "Действия".
2. Таблица "Ассоциированные документы", где действиям присвоены ид документов.
3. Таблица "Документы" с полями серии, номера, даты начала и окончания, выдавшей организации, подписавшего человека.
4. Таблица "Юрлица", связанная с таблицей "Документы" по ид_юрлица" - для получения в запросе наименования юрлица, выдавшего документ.
5. Таблица "Физлица", связанная с таблицей "Документы" по ид_физлица" - для получения в запросе наименования физлица, подписавшего документ.
И что с этими таблицами не так? Вполне нормальная структура.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395800
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelНа одном действии, например "Присвоение сотруднику квалификационной категории", может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении"
В этом месте у меня зарождается сомнение. Не буду выдавать всю цепочку размышлений, просто скажу результат: имхо, весь этот механизм в итоге приходит к примерно следующему дереву:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Вышестоящий приказ о присвоении
|
+-- Приказ о присвоении сотрудникам первой категории
|   |
|   +-- Присвоение категории Иванову
|   |
|   +-- Присвоение категории Петрову
|
+-- Приказ о присвоении сотрудникам второй категории
    |
    +-- Присвоение категории Сидорову
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395846
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerOkeTurelНа одном действии, например "Присвоение сотруднику квалификационной категории", может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении"
В этом месте у меня зарождается сомнение. Не буду выдавать всю цепочку размышлений, просто скажу результат: имхо, весь этот механизм в итоге приходит к примерно следующему дереву:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Вышестоящий приказ о присвоении
|
+-- Приказ о присвоении сотрудникам первой категории
|   |
|   +-- Присвоение категории Иванову
|   |
|   +-- Присвоение категории Петрову
|
+-- Приказ о присвоении сотрудникам второй категории
    |
    +-- Присвоение категории Сидорову

Вот мне тоже кажется, что у действия есть основание и это один документ, а у последнего в свою очередь своё основание.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395923
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelЯ не могу никак увязать две сущности - действие и документ.
OkeTurelПосоветуйте что-нибудь, а то я запуталась. Что выбрать? Я хочу сделать по правилам.

К черту все правила... - всего и будет две таблицы (не учитывая прочей мишуры типа дат и подписей), только нужно поставить все с головы на ноги - документ первичен, действия по нему вторичны...

- Все документы (и "Вышестоящие" и " Наши" в одной ГЛАВНОЙ таблице docs )
- Если документ "Вышестоящий" (выше уже не бывает), то значение owner (владелец) у него равно нулю (или null, кому как, но мне лучше ноль - ибо это конкретная величина) и соответственно, действий по нему В ПОДЧИНЕННОЙ таблице Actions может и не быть (а могут и быть).
- Если документ " Наш", то значение owner у него содержит id_doc "Вышестоящего" документа из этой же таблицы Docs и соответственно в подчиненной таблице Actions есть вся движуха по этому документу...
Преимущества:
- Документов с owner = 0 "Вышестоящих" будет мало (по вашим же словам) и вы в запросах будете оперировать только с теми документами у которых owner > 0 с "Вашими" документами.
- Не ограниченный уровень иерархии подчинения документов (например, сначала был приказ, потом директива со ссылкой на приказ, а потом уже внутренний приказ со ссылкой на директиву и естественно уже и действиями в Actions).
- при желании "Вышестоящие" документы можно упаковывать и хранить как "Наши", например описывая в Actions их краткое содержание, суть и т.д.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395924
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vmag- Не ограниченный уровень иерархии подчинения документов (например, сначала был приказ, потом директива со ссылкой на приказ, а потом уже внутренний приказ со ссылкой на директиву и естественно уже и действиями в Actions).

Если такое будет, то в таблицу Docs добавить дополнительный признак наш/не наш дабы отделить мух от котлет...
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39395929
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
в общем имхо окончательный вариант таки с признаком наш/не наш (my) на случай если иерархия документов больше двух или если вообще нет "вышестоящих" документов, а только "наш", тогда признаки в записях ставим по ситуации:
1. Вышестоящий документ верхнего уровня:
owner = 0
my = False (не "наш")
2. Вышестоящий документ промежуточный или нижнего уровня:
owner = id_doc вышестоящего
my = False (не "наш")
3. Наш документ имеющий Вышестоящий документ:
owner = id_doc вышестоящего
my = True ("наш")
4. Наш документ не имеющий Вышестоящего документа (сам по себе):
owner = 0
my = True ("наш")
Естественно основная работа теперь будет по признаку my = True ("наш")
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396086
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vmag,
Может быть ситуация, что с одним действием связаны несколько документов. А эти документы при этом не связаны между собой по типу главный / подчиненный. Например, есть приказ о присвоении категории, а есть к примеру медицинская справка об обследовании, которое должно выполняться при смене категории. То есть к одному действию надо присоединить два документа. Так что без дополнительной таблицы связи многие ко многим не обойтись.

Да и связи между документами могут быть не такими однозначным. Например, есть приказ вышестоящей организации о присвоении категории тем, кто прошел тесты. И есть протокол проведения тестирования сотрудников. И у приказа о присвоении категории будет два вышестоящих документа - вышестоящий приказ и протокол тестирования. А это еще одна таблица связей. :)
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396090
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot Но когда я так делаю, то запросы получаются совершенно безумные по объему и сложности, потому что действий полно, а один документ может висеть на разных действиях. Выглядит ужасно и работает через пень-колоду.


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

(очень мало действий, на которых висело бы сразу 2 документа). Но зато запросы меньше и аккуратнее и работают чище.

не бывает "2".
Либо один, либо больше одного - т. е . много.


я думаю, тебе не надо паниковать, а надо делать как задумано по ТЗ, т. е. про первому варианту, одно действие - много документов.

база данных не должна быть удобной для запросов, она должна быть адекватна по структуре своей задаче.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396093
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelКот Матроскин, спасибо за ответ.
Понимаете, на самом деле получается гораздо больше таблиц в запросе! Вовсе не две!
1.

назови цифру, от которой ты бы считала, что в запросе много таблиц.
потом я назову свою.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396098
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurel,

вообще, покажи свою структуру уже... начальный или оба варианта
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396144
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivназови цифру, от которой ты бы считала, что в запросе много таблиц.
потом я назову свою.

Точно, давайте меряться количеством таблиц!

Код: sql
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.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
  FROM [Analysis].[Track Entry] as track
	
	inner join [Analysis].[Track] as track_id
		  on track.[Track ID] = track_id.[Track ID]

    inner join [Analysis].[Track Calculate - ILE]  as ile_step0 
		  on track_id.[First Step Item Ledger Entry No] = ile_step0.[Entry No_]
		  and track_id.[First Step Company ID] = ile_step0.[Company ID]

    inner join [Analysis].[Track Calculate - ILE]  as ile
		  on track.[Item Ledger Entry No] = ile.[Entry No_]
		  and track.[Item Ledger Company ID] = ile.[Company ID]

	left join 
		(select 
		ile.[Company ID]
		,ile.[Entry No_] as [Item Ledger Entry No]
		,min(ve.[Entry No_]) as [Min Value Entry No]
		from [Analysis].[Track Calculate - ILE]  as ile

			inner join [Analysis].[Track Calculate - VE] as ve
				  on ve.[Item Ledger Entry No_] = ile.[Entry No_]
				  and ve.[Company ID] = ile.[Company ID]

		group by
		ile.[Company ID]
		,ile.[Entry No_]) as next_ile_min_ve
		on next_ile_min_ve.[Company ID] = track.[Next Item Ledger Company ID]
		and next_ile_min_ve.[Item Ledger Entry No] = track.[Next Item Ledger Entry No]
		  
    inner join [Analysis].[Track Calculate - VE] as ve
		  on ve.[Item Ledger Entry No_] = ile.[Entry No_]
		  and ve.[Company ID] = ile.[Company ID]
		  and 
				(  
					 (  
					   (ve.[Item Ledger Entry Type] = 0 or ve.[Entry Type] = 2)
                        and not (ile.[Entry Type] = 0 and ile.Positive = 0 and ve.[Cost Amount (Non-Invtbl_)] = 0)
					  )
					or (ile.[Entry Type] = 2 and ve.Adjustment = 0)
					or ve.[Item Ledger Entry Quantity] <> 0
					or ve.[Entry Type] = 2
					or (ve.[Item Ledger Entry Type] = 1 and ve.[Expected Cost] = 0)
				)
--------revaluation / no revaluation
----- MSDN Nav Design Details: Revaluation
----- Determining if an Inventory Decrease Is Affected by Revaluation
		  and 
			  (
			  	     (ve.[Entry Type] <> 1
				   --or ve.[Valued Quantity] = ile.Quantity --in database we have mistakes with [Valued Quantity]
                   --or ve_next_ile.[Entry No_] is null 
				   or track.[Next Item Ledger Entry No] = 0
				   --or track.[Item Ledger Entry Quantity] = -1 * track.[Next Item Application Entry Quantity]
				   or (ve.[Entry Type] = 1 and ve.[Partial Revaluation] = 0)	
				   )
			   or
			    (ve.[Company ID] = next_ile_min_ve.[Company ID]
				and
			      (not (next_ile_min_ve.[Min Value Entry No] < ve.[Entry No_]
				        and track.[Next Item Ledger Entry Posting Date] <= ve.[Valuation Date] )
				  )
                 )
			   )
------------------------------------
	inner join [Analysis].[Item] as item
		  on ile.[Item No_] = item.No_

	inner join [Analysis].[Location] as location
		  on ile.[Location Code] = location.Code

    left join [Analysis].[Track Calculate - ILE]  as ile_prev
		  on track.[Previous Item Ledger Entry No] = ile_prev.[Entry No_]
		  and track.[Previous Item Ledger Company ID] = ile_prev.[Company ID]

    left join [Analysis].[Purch_ Rcpt_ Line] as rcpt_line
		  on ile_step0.[Document Type] = 5
		  and ile_step0.[Document No_] = rcpt_line.[Document No_]
		  and ile_step0.[Document Line No_] = rcpt_line.[Line No_]
		  AND ile_step0.[Company ID] = rcpt_line.[Company ID]

    left join [Analysis].[Sales Shipment Line] as ship_line
		  on ile.[Document Type] = 1
		  and ile.[Document No_] = ship_line.[Document No_]
		  and ile.[Document Line No_] = ship_line.[Line No_]
		  AND ile.[Company ID] = ship_line.[Company ID]

    left join [Analysis].[Sales Shipment Line] as ship_line_prev
		  on ile_prev.[Document Type] = 1
		  and ile_prev.[Document No_] = ship_line_prev.[Document No_]
		  and ile_prev.[Document Line No_] = ship_line_prev.[Line No_]
		  AND ile_prev.[Company ID] = ship_line_prev.[Company ID]

    left join [Analysis].[Sales Invoice Line] as sal_inv_line
		  on ve.[Document Type] = 2
		  and ve.[Document No_] = sal_inv_line.[Document No_]
		  and ve.[Document Line No_] = sal_inv_line.[Line No_]
		  AND ve.[Company ID] = sal_inv_line.[Company ID]

    left join [Analysis].[Sales Cr_Memo Line] as sal_crm_line
		  on ve.[Document Type] = 4
		  and ve.[Document No_] = sal_crm_line.[Document No_]
		  and ve.[Document Line No_] = sal_crm_line.[Line No_]
		  AND ve.[Company ID] = sal_crm_line.[Company ID]


	left join 
		(select    [Item No_]
					,[code]
					,[Qty_ per Unit of Measure] 
		from [Analysis].[Item Unit of Measure]
		where [code] = 'MT') as uom_mt
	      on uom_mt.[Item No_] = ile.[Item No_]

	left join [Analysis].[Operation Entry (Table)] as old_operation
	on old_operation.[Track ID] = track.[Track ID]
	and old_operation.[Value Entry No] = ve.[Entry No_]
	and old_operation.[Item Ledger Company ID] = track.[Item Ledger Company ID]
	and old_operation.[Item Ledger Entry No] = track.[Item Ledger Entry No]


	where old_operation.[Track ID] is null
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396171
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinovvmag,
Может быть ситуация, что с одним действием связаны несколько документов. А эти документы при этом не связаны между собой по типу главный / подчиненный. Например, есть приказ о присвоении категории, а есть к примеру медицинская справка об обследовании,

ИМХО вы собрали в кучу не собираемое (приказ о присвоении очередного воинского звания со справкой в бассейн)...
в Docs руководящие документы, а если нудны подтверждающие документы (иногда), то проще завести дополнительную таблицу для этого и повесить её уже на таблицу Actions как подчиненную...
Но даже в той прошлой моей последней схеме ваша проблема решается на ура добавлением еще одного признака в таблицу Docs - статус документа (например 1 это руководящий, 2 - сопутствующий)
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396323
Фотография ПЕНСИОНЕРКА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelЯ не могу никак увязать две сущности - действие и документ. На одном действии, например "Присвоение сотруднику квалификационной категории", может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении".

я бы сочла, что это типа ежедневника или контроля исполнения документов
номерном для ссылки на вышестояший автордатаназваниеисполнительдата исполнение статус10директор10/01/2017наградить женщин к 8 мартапрофком20/02/2017110директор02/03/2017выдать женщинам по хххх руббухгалтерия06/03/201720директор11/01/2017наградить участников вовсовет ветеранов10/02/2017вып120директор22/02/2017выдать ветеранам по хххх руббухгалтерия23/02/201731профком12/01/2017запрос в отдел кадров на работающих женщин старше 30 летотдел кадров14/01/2017вып41профком14/01/2017роздать цехам спискисеменова15/01/2017вып51профком18/01/2017получить спискисеменова20/01/201762совет ветеранов19/01/2017запрос в отдел кадров на работающих ветерановотдел кадров20/01/2017вып72совет ветеранов20/01/2017составить и выверить списки пенсионеров-ветерановильина22/01/2017вып82совет ветеранов25/01/2017оформить ответ в дирекциюильина26/01/2017вып
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396450
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте. :^)

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

[img] http://savepic.net/8882997.jpg [/img]
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396483
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelЗдравствуйте. :^)

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

[img] http://savepic.net/8882997.jpg [/img]
Для начала требуется вашу структуру немного упорядочить, чтобы связи через весь экран не проходили...
Вы сами вашу структуру в таком виде понимаете?
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396515
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добавлю, что у меня кадровая база, т.к. я кадровик, а специализированных кадровых систем типа 1-С или Паруса у нас нет. Приходится пыхтеть самой. :)

Уважаемые ответившие, у меня в таблице "Документы" ЕСТЬ 2 поля document_id и document1_id, и второе поле как раз для наддокумента. Я им пользовалась для допсоглашений к трудовым договорам: трудовой договор - наддокумент для допсоглашения, другими словами - допсоглашение подчинено трудовому договору. Но в случае с приказами я не пользовалась этим, а теперь поняла, что да, вышестоящий областной приказ - наддокумент для нашего внутреннего приказа. Когда я вставила эту связь, то запрос заработал более-менее сносно.
Хотя я согласна с s_ustinov, могут быть и два несвязанных между собой документа, висящие на одном действии. Тогда запрос выдает на одного сотрудника 2 строки. А это нельзя, потому что из запроса все экспортируется программно в Эксель в бланк приказа. Но с другой стороны, действительно можно добавить дополнительные свойства документам, типа "руководящий", "сопутствующий", как советует vmag. И в запросе отсеять только нашей организации документы. А с третьей стороны, можно предельно "раздробить" действия, сделать их очень мелкими, и тогда, наверно, будет одно действие - один документ, как и пишет skyANA.

SERG1257, я сейчас попробовала без этого, но если будет продолжаться с моей базой такая петрушка, то придётся. Устала разбираться в собственных запросах. :)

MasterZiv, у меня в одном запросе 9 таблиц, из этих таблиц 6 штук - на самом деле не таблицы, а другие запросы, которые сами состоят из таблиц числом от четырех до семи. Можно ли это считать нормальным?

аля1ц, я не хочу в Эксель, мне он не нравится. )

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

ПЕНСИОНЕРКА, да, похоже на мою таблицу "документы".

Большое спасибо, что ответили мне. :)
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396518
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov, как это упорядочить структуру, там структура нелинейная, не типа "ступенька - другая ступенька", а все перемешано. Все равно будут косые линии.
Если приглядеться, то понимаю. )
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396525
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurels_ustinov, как это упорядочить структуру, там структура нелинейная, не типа "ступенька - другая ступенька", а все перемешано. Все равно будут косые линии.
Если приглядеться, то понимаю. )
Речь не о косых линиях.
При проектировании БД стараются таблицы располагать группами. И чтобы большая часть связей была внутри групп, а между группами было 1-2 связи, а не паутина.
У вас вроде так не получается, так как много "петель". Скорее всего, надо повысить уровень нормализации.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39396535
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer, это все так красиво выглядит, как Вы начертили, а на деле не знаю даже, на каждой таблице куча других - кто подписал документ, какая организация издала, если трудовой договор - то на какой основании действует подписавший. Возможно, надо избавиться от некоторой информации, хотя и жалко.
...
Рейтинг: 0 / 0
25 сообщений из 63, страница 1 из 3
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование без избыточности
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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