|
|
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
Всем привет. В базе, с которой я имею дело, имеет место следующая ситуация. Имеется таблица, в которой хранятся данные "объектов" разных "классов". Причем ряд полей, с одинаковыми названиями, хранят в себе значения, абсолютно разные по смыслу. К примету, поле Date1 может, в зависимости от того, об каких объектах идет речь, хранить либо "Дату начала", либо "дату окончания", либо "Дату начала" и "дату окончания" одновременно (Update после совершения некоторого события), либо что-то еще. Соответственно, если надо отобрать объекты некоторого набора "классов" в зависимости от смыслового содержания, к примеру, дат, приходится строить трехэтажные условия отбора в where, а затем это все очень сложно проверять, так как все это еще практически недокументировано. Интересует отношение форумного разума к такой структуре данных. Насколько допустимо хранить в одних и тех же полях разные по смыслу данные. Особенно интересут мнение насчет update этих полей. Насколько это приемлемо? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 09:55 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
имхо нормальная ситуация ... с единственной оговоркой - если "объекты" разных "классов" просматриваются/редактируются каждый в своей "оболочке" заточенной под определенный "класс" - проблем здесь быть не должно ... конечна когда необходимо строить некоторые "сводные" отчеты - тогда и всплывает описанный гемморой ... но лична я считаю что эта допустимая плата за такой условно "универсальный" способ хранения :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 10:04 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
NSFuimus, ну-у я с тобой не согласен. Я сторонник того, чтобы в поле с одним названием хранилось бы значение, одинаковое по смыслу для всех объектов разных классов. То есть если есть поле Дата1, и некто решил наделить это поле смыслом "Дата начала", то такой смысл это поле должно иметь для объектов ВСЕХ "классов". Иначе возникает полная путаница. И еще я не сторонник Update, особенно таких, которые меняют смысл содержимого поля. Я думаю, что это не правильно. Если нужны какие-то специфичные поля для объектов нового "класса", никто не мешает сделать таблицу SpecifiicFieldClass2 - и вынести их туда. А то получается, что каждый новый "класс" "пытается" использовать уже имеющиеся для другой цели поля в таблице для своих целей, и если возникает задача совместно использовать эти поля для объектов разных классов, разобраться становиться совершенно невозможно. Представьте для примера ситуацию, когда есть 3 класса, 5 идентичных (но в чем-то различных) полей, каждое из которых еще и апдейтится. Получается уже 30 смысловых вариантов. Бр-р-р. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 10:22 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
TRJНасколько допустимо хранить в одних и тех же полях разные по смыслу данные.Настолько, насколько для данного случая плюсы перевешивают минусы. Плюсами может быть например упрощение каких-то общих процедур, уменьшение числа таблиц и джойнов (иначе бы вылезли за лимит полей). Химическое: Грязь - это химические вещества не на своем месте. Остается только определить это самое место. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 10:36 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
я тебя понимаю ... ну давай конкретный пример ... есть справочник типа "контрагентов" ("контрагенты" могут быть "юриками" а могут быть "физиками") он имеет завязки на кучу таблиц ... считаю абсолютна правильным как ты говоришь для того чтобы не городить для каждого "класса" ("юрик" или "физик") свою таблицу(ы) связи "на сторону" создавать некую общую таблицу а все специфические поля - по связи 1-к-1 в "специфические" таблицы ... давай подумаем какие реквизиты мы можем вынести в эту общую таблицу (кроме служебных имеется ввиду) ... адрес раз ... ну ты можешь продолжить ... но мы имеем некий общий реквизит - наименование ... в одном случае - это фамилия, в другом - имя организации ... в принципе я имел ввиду именно такое "разночтение" ... но сложности ввиду неоднозначности здесь присутсвуют ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 10:39 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
Я думаю, что главное - это логическая стройность смыслового наполнения базы. А количество джойнов, процедуры - это все вторично. Второе должно служить первому, а не наоборот. Никаких плюсов применения вышеназванного подхода я не вижу, причины его - простая лень, а следствие - бардак и хаос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 10:43 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
NSFuimusя тебя понимаю ... ну давай конкретный пример Примеры? Пожалуйста. Предположим, в ЗАГС ведутся какие-то договора. Договора лежат в одной таблице. Пусть будет 3 договоров. 1 - Свадебные договора 2 - Договора аренды квартир 3 - Договора регистрации транспортных средств. В результате получили такую структуру: 1. Date1: Дата регистрации брака Date2: Дата расторжения брака 2. Date1: Дата заключения договора аренды квартиры Date1: Дата выселения арендатора (после расторжения договора аренды квартиры) Date2: Дата проверки договора инспекцией Date3: Дата расторжения (закрытия) договора аренды 3. Date1: Дата проверки транспортного средства Date2: Дата начала действия договора регистрации транспортого средства Date3: Дата аннулирования договора транспортного средства и т. п. Все примеры, разумеется, "от фонаря". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 10:59 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
эээ ... ты ждешь от меня комментария? ... пжалста ... как видим имеем как минимум две даты общих для всех договоров - Date1 и Date2 ... не имея полной постановки задачи я решу что в данном случае "плюсы перевешивают минусы" и вынесу эти даты в общую таблицу ... далее в метаданных 1. в SQL для конкретной формы служащей для вывода информации по определенному договору в секции SELECT напишу, например для свадебных договоров, ... Date1 AS DTREGISTRATION, Date2 AS DTUNREGISTRATION ... 2. в таблице описывающей поля системы добавлю 2 записи: Дата регистрации брака | DTREGISTRATION | исходная таблица | Date1 ... и Дата расторжения брака | DTUNREGISTRATION | исходная таблица | Date2 ... все это чрезвычайно упрощенно, но ... примерно так все и обстоит ... теперь и для настройки на клиенте конечным пользователем интерфейса и при формировании update-ов на сервере программистом мы можем однозначно все определить и фсе щастливы ... повторяю еще раз - все это - "не имея полной постановки задачи" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 11:15 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
Ну-у-у, клиенты клиентами... А потом пришел начальник ЗАГС и задал такие вопросы: задачу: 1) сколько договоров любого вида заключено в такой-то интервал дат? 2) Сколько договоров закрыто в такой-то интервал дат 3) Сколько договоров заключено и закрыто в такой-то интервал дат И.т.п При приведенной мною структуре отвечать на такие вопросы не слишком удобно. Из-за того, что общая, характерная для договора любого вида семантика не обособлена в базе и размазана по разным местам. За деревьями не стало видно леса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 11:29 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
прошу прощения, подписался не так. Предыдущее сообщение мое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 11:30 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
ты меня извини канешна ... но дата создания договора не тоже самое что и дата регистрации брака ... то же самое относится и к дате закрытия договора/расторжения брака ... эта раз ... правильно было сказано - смотреть по обстановке ... эта два ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 11:36 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
авторНасколько допустимо хранить в одних и тех же полях разные по смыслу данные. а потом как в анеке: чертовски трудно раскуривать что куда и откуда для лабания юзеру какого-нить простенького отчета... можно завести деревянную таблитцу и там свойства хранить ... но тож не удобно для того кто потом будет ковыряться в Ваших бд :) мож все-таки по-людски делать ? Date1, Date2, Date3 - пускай что-то будет нулл для одного из договоров ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 12:13 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
=кгма потом как в анеке: чертовски трудно раскуривать что куда и откуда для лабания юзеру какого-нить простенького отчета... можно завести деревянную таблитцу и там свойства хранить ... но тож не удобно для того кто потом будет ковыряться в Ваших бд :) мож все-таки по-людски делать ? Date1, Date2, Date3 - пускай что-то будет нулл для одного из договоров ? кгм..., то есть ты за хранение разных по смыслу значений в одном поле? А как насчет Update, который после наступления определенного события втыкает вместо одного по смыслу значения, другое. Допустимо это или нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 13:17 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
TRJВсем привет. Насколько это приемлемо? Я, например, в силу природной лени и тупости обычно собираю справочники примерно так create table SPR ( NZ NUMBER(9) not null, USR NUMBER(9) not null, DAT_USR DATE not null, TIP_SPR NUMBER(9) not null, NAZV_SPR VARCHAR2(20) not null, PAR_NUM NUMBER(9) default 0 not null, PAR_DAT DATE, PAR_STR VARCHAR2(250), PAR_STR2 VARCHAR2(250), PAR_STR3 VARCHAR2(250), DLT NUMBER(9) default 0 not null )[quot автор] меня ломает делать кучу справочников когда , я могу все засунуть в адну табулицу. И примерно так же сделана таблица свойств каких-либо объектов, так сказать (лень*реляция). PS на самом деле канечна посложнее ,но принцЫп такой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 13:44 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
TRJкгм..., то есть ты за хранение разных по смыслу значений в одном поле? нет, я против. я хотел сказать пускай лучше будет избыточность чем разные по смыслу в одном ... TRJА как насчет Update, который после наступления определенного события втыкает вместо одного по смыслу значения, другое. Допустимо это или нет? не допустимо :) ну или как правильно имхо сказал barsukof - одна таблица с общими свойствами договоров + табл. с доп. свойствами ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 15:26 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
Покажу эту ветку проектировщикам. Пусть посмотрят, что коллективный разум о них думает :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 17:12 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
TRJ Насколько это приемлемо? Приемлемо, если с этой базой работать только с помощью специально под нее спроектированных клиентов, к-е сами умеют строить "трехэтажные условия отбора в where" и т.п. Если же у вас такого клиента нет или он не может реализовать то, что вам нужно - передавайте привет архитекторам, к-е черезчур увлеклись "красивым, универсальным решением" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 17:33 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
Alexey KudinovПриемлемо, если с этой базой работать только с помощью специально под нее спроектированных клиентов, к-е сами умеют строить "трехэтажные условия отбора в where" и т.п. Или через вьюхи, процедуры и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 17:39 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
Сергей ВаскецовИли через вьюхи, процедуры и т.п. Согласен с уточнением. Главное - иметь "API" для работы с такой структурой данных и работать только через него. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 17:49 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
Alexey Kudinov Сергей ВаскецовИли через вьюхи, процедуры и т.п. Согласен с уточнением. Главное - иметь "API" для работы с такой структурой данных и работать только через него. Вообще это весьма оригинальное решение. Одни наводят в базе кривизну. Другие пишут API, который эту кривизну нивелирует... Вообще-то мысль про API неплохая, только любой API - это лишний слой, который замедляет работу. Наверное, лучше сразу по возможности нормально делать. Уж если не вышло - тогда уж API. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 17:58 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
TRJОдни наводят в базе кривизну. Другие пишут API, который эту кривизну нивелирует... Необходимо определиться, что первично, а что нет. Может быть, Вы считаете это кривизной потому, что с этим сложно работать? Тогда наличие некоего обобщенного API как раз и устраняет эту проблему, соответственно, кривизны как раз и нет, а есть наоборот, простота и красота. ИМХО. в одном поле могут быть принципиально разные вещи, но для разных типов сущностей. Тип сущности в этом случае не может изменяться update-ом и не должен определяться по таким полям. Соответственно, смысл таких полей update-ом не меняется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 18:03 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
NSFuimusты меня извини канешна ... но дата создания договора не тоже самое что и дата регистрации брака ... то же самое относится и к дате закрытия договора/расторжения брака ... эта раз ... правильно было сказано - смотреть по обстановке ... эта два ... В этом все и дело. Между этими датами могут быть достаточно тонкие различия, - однако описание этих полей может быть одинаковое для разных "классов", не говоря уже о том, что лежат они в одном поле. И когда возникает необходимость отобрать что-то из разных "классов" по этим полям, возникает... проблема. И чем тоньше различие, тем проблема больше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 18:19 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
> Имеется таблица, в которой хранятся данные "объектов" разных "классов". Ни "объектов", ни "классов" в реляционной СУБД храниться не может. По определению. Есть условия, при которые "объекты" и "классы" по отношению к реляционным СУБД - не пустой набор звуков, однако, сильно вряд ли об этом идет речь в данном случае. > Насколько допустимо хранить в одних и тех же полях разные по смыслу данные. Недопустимо. Это ошибка. К сожалению, скоро можно будет сказать "типичная ошибка". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 20:15 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
TRJПокажу эту ветку проектировщикам. Пусть посмотрят, что коллективный разум о них думает :-) Вспомнилось одно давнее обсуждение на этом форуме, если они (проектировщики) еще не видели, то вероятно им будет интересно. В предлагаемой модели "объект-качество" (автор - U-gene - Евгений Григорьев) вопрос "Насколько допустимо хранить в одних и тех же полях разные по смыслу данные?" звучал бы чуть по-другому... Главную идею можно передать парой цитат: «Создавая объектную систему на базе аппратного компьютера мы ВЫНУЖДЕНЫ представлять наши объекты как набор переменных простых типов. Создавая объектную систему на базе реляционной БД мы должны представить ее как совокупность переменных типа "отношение", поскольку это единтсвенный тип, реализуемый реляционными системами.» и далее: «Это не маппинг. Маппинг подразумевает, что данные преобразуются из "объектных структур в реляционные". У меня объекты изначально представляют собой совокупность реляционных структур. А зачем преобразовывать что-то во что-то если требуемое уже и так есть?» В такой модели вопрос стоял бы не о разных смыслах значений одного поля а о разных смыслах записей одной таблицы (отношения) - т.е. разных смыслах разных переменных, хоть и одного типа... Тогда, например, можно было бы иметь "реляционный тип" (таблицу) - Период с полями Date1, Date2, S где Date1 и Date2 имеют всегда имеют один и тот же "реляционный" смысл (начало и конец периода), а S содержит "объектный" смысл ("рождение-смерть", "женились-развелись", срок аренды и т.п.) ps. первые две ссылки из того обсуждения на авторскую статью не открылись, и я уже не помню что это за статья, но вот ссылки на несколько его статей: http://www.citforum.ru/database/articles/ooo_rel_data/ http://www.citforum.ru/database/articles/moq.shtml http://www.osp.ru/os/2000/01-02/178205/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2007, 22:40 |
|
||
|
Разное по смыслу содержание полей разнородных объектов в одной таблице
|
|||
|---|---|---|---|
|
#18+
> U-gene - Евгений Григорьев До сих пор фетишей было два: Celco и Тенцер. Теперь три. Абсолютная, полная, безграмотная шуклятина. P.S. Шуклятина - производное от Шуклин. Есть тут такой недоумок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2007, 01:03 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=34257916&tid=1544690]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
182ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
88ms |
get tp. blocked users: |
1ms |
| others: | 222ms |
| total: | 542ms |

| 0 / 0 |
