Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Принцип хранения данных / 8 сообщений из 8, страница 1 из 1
21.02.2002, 05:49
    #32023582
Flamer
Flamer
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Принцип хранения данных
Добрый день, отцы!

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

Итак: имеем информацию о предприятии. Постулат - все свойства предприятия должны храниться в одной таблице (только логин и пароль в отдельной). Условия:

1. Название у предприятия одно.
2. Адресов может быть несколько (типа юридический, фактический, представительство). Причем тип адреса важен.
3. Адрес разбит на следующие составляющие - Почтовый индекс, страна, город, собственно адрес.
4. Телефонов/факсов для каждого адреса может быть несколько. Необходимо иметь возможность различать тип номера (телефон/факс).
5. Ответственных лиц для каждого адреса несколько.
6. Реквизитов несколько для каждого адреса. Они тоже разбиты на секции - РС, КС и пр. банковская муйня.
7. ...

Что требуют - легкое добавление нового свойства для предприятия (например, подсвойство Переулок для адреса).

СОбственно, хотелось бы все данные по предприятию вытащить одним селектом. Набросал я одну структуру, но чего-то не так - не получается однозначно привязать индекс к адресу (если адреса два) в селекте... Структура простая - есть таблица секций (Адрес, Реквизиты) и таблица подсекций (Страна, Город)... Очевидно, что в этой структуре есть слабое место...

Надеюсь, донес все понятно. Помогите плз - пивом напою
)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.02.2002, 06:50
    #32023590
ASCRUS
ASCRUS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Принцип хранения данных
Судя по Вашему вопросу вы хотите получить универсальную структуру, позволяющую самим клиентам легко ее модифицировать. Я бы порекомендовал бросить эту затею по нескольким причинам:
1. Неоправданная универсальность бьет по скорости разработки программы, ее выполнения и добавляет кучу ошибок
2. Не надо забывать, что SQL в отличии от индексно-последовательных систем изначально расчитан на обработку множества данных с четко определенной структурой и Вам сложно будет по такой структуре все вытащить одним запросом

Так что легче сделать все старыми дедовскими методами по 3 нормальной форме и не заморачиваться. А универсальную структуру пытаются сделать только в 2 случаях: если у Вас тиражный продукт и эти атрибуты индивидуальны для каждого клиента (как в 1С) или если у вас нет четкой постановки задачи, что очень очень плохо.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.02.2002, 07:02
    #32023595
Flamer
Flamer
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Принцип хранения данных
Спасибо за ответ!

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

Все-таки какую структуру использовать? Графы не очень подходят в силу ряда причин...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.02.2002, 07:41
    #32023605
Replicant
Replicant
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Принцип хранения данных
2 ASCRUS:
>Судя по Вашему вопросу вы хотите получить универсальную структуру, позволяющую самим клиентам легко ее >модифицировать. Я бы порекомендовал бросить эту затею по нескольким причинам:
>1. Неоправданная универсальность бьет по скорости разработки программы, ее выполнения и добавляет кучу >ошибок

Абсолютно согласен...

2 Flamer:

>Что требуют - легкое добавление нового свойства для предприятия (например, подсвойство Переулок для >адреса).

Блажь, они сами не знают, что им нужно. Поэтому задача не поощрять их необузданные
и бессмысленные желания, а аккуратно объяснять "что да, всё универсально, но не до бесконечности"

>Продукт тиражный, все свойства предприятия уникальны для каждого предприятия...

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

>Требование заказчика - все параметры свойств предприятия хранить в одной таблице...

А может ему самому базу спроектировать и клиента написать? Надо ему сказать, что Майкрософт
такое запрещает делать...

>2. Адресов может быть несколько (типа юридический, фактический, представительство). Причем тип адреса >важен.
>3. Адрес разбит на следующие составляющие - Почтовый индекс, страна, город, собственно адрес.
>4. Телефонов/факсов для каждого адреса может быть несколько. Необходимо иметь возможность различать тип >номера (телефон/факс).
>5. Ответственных лиц для каждого адреса несколько.

Делается обычно так, сущности: ТИП_ПРЕДПРИЯТИЯ (ведь можно же их разделить на типы: промышленное, торговля, обслуживание итд), ПОДТИП_ПРЕДПРИЯТИЯ (подтипы: торговля: автомобили, повседневного спроса, компьютеры...);
родитель: ПРЕДПРИЯТИЕ (название, описание, тип), детки ПРЕДПРИЯТИЯ: АДРЕС (с признаком юридический, фактический, представительство; здесь все по максимуму: индекс, город, микрорайонЮ дом, улица, проуолок, переулок, строение, литера дома, подъезд, этаж, квартира и тд. если нет - то 0 или НУЛЬ), ТЕЛЕФОН (с признаком факса), ЛИЦА (ФИО, с ключамм на его должности, телефоны и адреса);
ДОЛЖНОСТИ (описание должностей, возможно субординация), АДРЕС_ЛИЦА, ТЕЛЕФОН_ЛИЦА....
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.02.2002, 08:24
    #32023614
nic_ii
nic_ii
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Принцип хранения данных
>Требование заказчика - все параметры свойств предприятия хранить в одной таблице...

Какой продвинутый у вас заказчик! Они что, собираются иметь доступ к этой самой таблице на физическом уровне ковыряя mdf файл? Если нет, то нужно думать как написать View или sp которая будет формировать им такую запись (набор записей) которую они хотят из набора таблиц, которые в нормальной форме описывают эти данные.
По моему так...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.02.2002, 12:43
    #32023656
Genady
Genady
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Принцип хранения данных
>Постулат - все свойства предприятия должны храниться в одной таблице (только логин и пароль в отдельной).

Посоветуйте взять Excel и не морочить вам голову.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.02.2002, 17:15
    #32023789
Garya
GaryaПривилегированный пользователь
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Принцип хранения данных
Если заказчик хочет сам проектировать структуру данных, пусть изучает Transact SQL и проектирует... Какие проблемы? Если вы попытаетесь дать ему другой инструмент, с помощью которого это можно делать, то сложность его будет соизмерима со сложностью того же SQL-сервера. Я сам бьюсь УЖЕ ОЧЕНЬ ДАВНО над подобной задачей. Дело движется, но очень медленно. Если интересуют идеи, то в двух словах универсальность достигается на иерархических справочниках с возможностью добавления произвольных свойств любым узлам дерева с возможностью наследования этих свойств низлежащими уровнями. Перечень свойств должен быть пополняемым. Свойства могут быть разных типов. Про скалярные типы рассказывать не буду - это ежу понятно. Сложные типы свойств - множество, ссылка на справочник и т.п. Свойства позволяют иметь разный набор "полей" на разных уровнях и узлах справочника.
Но еще раз повторяю! Делать такое - все равно, что чайной ложкой копать тунель длиной 10 км в горной породе.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.02.2002, 17:48
    #32023794
Alexander_Chepack
Alexander_Chepack
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Принцип хранения данных
С одной стороны - Продукт тиражный
С другой - Требование заказчика


Которого из заказчиков?
Делюсь опытом - пошлите Вы этого заказчика - делайте так, как правильно, а не так,
как заказчик хочет - когда все работать будет, виноваты будете Вы, а не заказчик.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Принцип хранения данных / 8 сообщений из 8, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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