powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Принцип хранения данных
8 сообщений из 8, страница 1 из 1
Принцип хранения данных
    #32023582
Flamer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый день, отцы!

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

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

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

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

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

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

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

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

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

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

2 Flamer:

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

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

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

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

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

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

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

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

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

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


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


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