|
|
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
в табле нужно хранить числовой параметр, либо диапазон, либо точное значение вот я думаю, нужны только два поля: from, to а другие говорят: три поля: from, to, exactly Кто прав? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 06:20 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
Я бы сделал только 2 поля. Если точное значение - то поля равны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 07:46 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
ага, логично но просто авторитет того, кто говорит про три поля, давит)) какие преимущества есть в трех полях? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 07:51 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
Cookieкакие преимущества есть в трех полях? Возможность внести в таблицу бредовые (aka противоречивые) данные, и соответственно необходимость в дополнительном констрейнте вида Код: plaintext Это неправильная постановка вопроса. Exactly - это дополнительная, необязательная сущность. Поэтому ее присутствие - и вызываемые им проблемы - должны быть обусловлены получаемым в связи с этим преимуществом. Какие преимущества из этого можно получить - я лично не вижу; разве что возможность проиндексировать это поле, но зачем может пригодиться такой индекс - хз. В целом, очень похоже на любимое неопытными разработчиками намерение из туманных и малопонятных общих соображений организовать конкретный геморрой на собственную задницу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 09:40 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
немного по другому если значение точно 2, тогда exactly=2, from=null, to=null если значение от 1 до 2, тогда exactly=null, from=1, to=2 т.е. плюсов никаких не видно? ЗЫ боюсь спорить на эту тему с таким серьезным специалистом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 09:49 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
Cookie если значение точно 2, тогда exactly=2, from=null, to=null если значение от 1 до 2, тогда exactly=null, from=1, to=2 Тогда все равно нужен констрейнт - проверять, что либо то, либо другое null - но все еще веселее, поскольку простейший запрос вида "есть ли в таблице значение X" будет выглядеть так: Код: plaintext и что важнее - выполняться это будет не слишком-то быстро. В общем: для того, чтобы ввести такую структуру, нужно серьезное обоснование - нафига это нужно и какие конкретные преимущества это даст. Если Ваши оппоненты выдвинут такую аргументацию - можно будет ее обсудить, до тех пор никаких причин так делать я не вижу. CookieЗЫ боюсь спорить на эту тему с таким серьезным специалистом Пора менять ник :(( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 09:58 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
почему поменять ник? на какой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 10:04 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
softwarer CookieЗЫ боюсь спорить на эту тему с таким серьезным специалистом Пора менять ник :(( )) Боюсь, уважаемый softwarer, он имел в виду не Вас. :) А того кто предлагал эти три поля. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 14:51 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
О. Вы меня порадовали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 15:51 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
> Кто прав? Без формулирования задачи невозможно сказать. Если переменная, принимающая значение из заданного диапазона - дискретная, я бы сделал from, to, step, exactly. Если step всегда фиксированный, то from, to, exactly. Исходную задачу опишите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 16:35 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
guest_20040621from, to, step, exactly мощно, ничего не скажешь :) на вопрос: 2-а поля или 3-и? отвечаем - 4-ре! :) а зачем 4-ре, можно спросить? Cookieкакие преимущества есть в трех полях? если, например, третье поле логическое "Экзектли - Йес/Ноу" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 16:47 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
> а зачем 4-ре, можно спросить? ПАтАму ШтА. Где в условии сказано, что диапазон - равномерный? Я бы вообще описывал произвольную последовательность, а не [арифметическую] прогрессию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 17:19 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
guest_20040621Я бы вообще описывал произвольную последовательность в одной записи? в одной таблице? неравномерный, значит, диапазон? произвольную, значит, последовательность? ну ладно, ладно - флаг как говорится в руки перечитай исходный вопрос... приведи пример данных для такой талбицы с четырьмя полями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 17:31 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
Три поля делают для того, чтобы при написании клиента не дай Бог потом код не писать. А нормальные люди делают два поля и две view для ненормальных людей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 17:46 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
guest_20040621 Исходную задачу опишите. числовой параметр, о котором мы говорим, снимается прибором, т.е. от дискретности никуда не уйдешь, соответственно, шаг - точность измерения))) параметр - характеристика объекта, который будет графически отображаться, это первая задача, по моему, тут два поля гораздо удобнее, от 12.2 до 12.2 - получается риска, от 12 до 13 - диапазон второе - всякие запросы, я тут думала, в любом случае кейсы всякие нужны ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 02:45 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
> числовой параметр, о котором мы говорим, снимается прибором Понятно. А что характеризует диапазон? Как получаются эти цифры? Как они попадают в базу данных? > по моему, тут два поля гораздо удобнее Imho нет. Например, три поля позволят уменьшить количество ошибок при вводе (если это делает оператор). Что предполагается дальше делать с данными? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 12:33 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
guest_20040621Imho нет. Например, три поля позволят уменьшить количество ошибок при вводе (если это делает оператор). Пожалуй, я сохраню ссылку на это Ваше письмо, чтобы в следующих беседах иметь возможность сослаться на непонимание Вами основ. Ввод данных и интерфейс оператора не имеют ровным счетом никакого отношения к структуре БД. Задача интерфейса - ввести данные так, как это следует делать с точки зрения ввода, например в трех полях (если это наилучший вариант). Задача БД - хранить данные так, как это следует делать с точки зрения последующей обработки, например в двух полях (если это наилучший вариант). Задача клиентского приложения в целом - служить драйвером/конвертором между "правильной БД" и "удобно пользователю", в частности, в данном случае, возможно, перекодировать "три в два". Явное нарушение этой модели свидетельствует о непонимании сути двухзвенной (хотя бы) архитектуры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 12:47 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
softwarerПожалуй, я сохраню ссылку на это Ваше письмо, чтобы в следующих беседах иметь возможность сослаться. думаете есть смысл? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 13:25 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
softwarer[quot guest_20040621]Ввод данных и интерфейс оператора не имеют ровным счетом никакого отношения к структуре БД. Задача интерфейса - ввести данные так, как это следует делать с точки зрения ввода, например в трех полях (если это наилучший вариант). Вот скажем такой интерфейс Чекбокс: Использовать прокси = нет Поле(ввод блокирован): имя прокси=zzz.ru Поле(ввод блокирован): номер порта=80 не попадался? Явно требует трех полей. Не исключено, что тот, кто хочет видеть 3 поля, имеет ввиду аналогичную логику. Если задано третье, игнорировать но не удалять значения первых двух. Хто его знает, что там за прибор и что меряет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 13:50 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
ModelRНе исключено. какой смысл гадать на кофейной гуще. кроме того вы приводите пример с логическим значением поля - этот вариант уже упоминался как преимущество при использовании трех полей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 13:59 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
proposed amendmentкакой смысл гадать на кофейной гуще.О том и речь. На простой вопрос есть простой ответ - может прав один а может другой:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 14:12 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
автор Вот скажем такой интерфейс Чекбокс: Использовать прокси = нет Поле(ввод блокирован): имя прокси=zzz.ru Поле(ввод блокирован): номер порта=80 не попадался? Явно требует трех полей. А еще есть примеры, когда три поля надо? А то не вспоминается ничего больше. А еще бы про четыре и пять полей тоже, на будущее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 14:15 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
> я сохраню ссылку на это Ваше письмо, чтобы в следующих беседах иметь > возможность сослаться на непонимание Вами основ. Рассказываю не понимаемые мной основы. Что дает exactly? Правильно, уважаемый, мы вводим понятие типа величины. Т. е. начинаем различать диапазоны и точные значение на уровне структуры данных. Эквивалентом до известной степени можно считать добавление в структуру данных valueType. Есть какие-то практические преференции? Естественно. Ошибки ввода не подготовленным специальным образом оператором - до 5%. Если используется только from, to, то ошибка ввода порождает сразу две ошибки: 1. собственно ошибочно введенное значение, 2. ошибка типа величины (вместо точного значения получили диапазон. Вторая ошибка - логическая - проистекает исключительно из-за кривой структуры данных. Надеюсь, понятно изложил? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 14:18 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
ModelRне попадался? Явно требует трех полей. Совершенно не явно. Вполне может оказаться так, что эту информацию будет оптимальным завернуть в XML, засунуть в EAV или извратиться над ней еще каким-нибудь образом. ModelRНе исключено, что тот, кто хочет видеть 3 поля, имеет ввиду аналогичную логику. Если задано третье, игнорировать но не удалять значения первых двух Не исключено. Почему я и сказал, что хотел бы выслушать его аргументацию. Если прочитаете мое письмо, я сказал что не представляю, зачем бы я делал именно так, но допускаю, что задача может этого потребовать. Если же говорить именно про аналогичную логику, то я бы советовал пять полей :) Потому что иначе во всех запросах есть серьезный риск забыть поставить фильтр и ложно найти "недействующие" записи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 15:53 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
Создаем таблицу с двумя полями: from, to. Поле to - nullable. Создаем 2 view. select [from], to from mytable where to is not null select [from] from mytable where to is null На клиенте ставим галку (радио) - значение/диапазон и в зависимости от либо пишем в одну, либо в другую view. Работает точно, проверил. Слабое место - не построишь ключь по nullable полю. Такое же слабое место и у таблицы с тремя значениями, там даже еще слабее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 16:05 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
> Создаем таблицу с двумя полями: from, to. Поле to - nullable. Еще раз, для тех, кто в танке: это плохое решение. Уже потому, что ограничения не отражены в структуре данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 16:10 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
guest_20040621 Еще раз, для тех, кто в танке: это плохое решение. Уже потому, что ограничения не отражены в структуре данных. Какое ограничение предметной области отражено в схеме с тремя полями и не отражено в этой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 16:26 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
Сторонники трех полей - ключи как будете строить и индексы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 16:29 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
из двух поле можно извлечь инф-цию: например фром=1, ту=-50 фром=21, ту=нуль фром=4, ту=4 значит третье поле не нужно в три поля можно ввести инф-цию не имеющую смысла: например фром=5, ту=3, екзакт=11 значит третье поле вредно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 16:32 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
> Какое ограничение предметной области отражено в схеме с тремя полями и > не отражено в этой? Первое сообщение треда не судьба прочесть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 16:33 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
> ключи как будете строить и индексы? Какие ключи? Какие индексы? ;))) Уважаемый, обсуждаемая структура данных не имеет практического применения ни в одной из рассматриваемых реализаций. Поэтому "как" - бессмысленный вопрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 16:37 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
Так чего париться об "ограничении предметной области", если таблица заведомо кривая и речь можно вести только об оптимальном размещении данных. Я бы вообще две таблицы сделал. И место бы сэкономил и с ключами-индексами проблем нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 16:45 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
> Так чего париться об "ограничении предметной области" Начальный вопрос был так задан. Как-то не очень красиво переформулировать его за автора. ;) > Я бы вообще две таблицы сделал Я бы тоже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 16:49 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
guest_20040621Рассказываю не понимаемые мной основы. Что дает exactly? Прежде всего - кому дает. Серверу? Клиенту? guest_20040621Если используется только from, to, то ошибка ввода порождает сразу две ошибки: Хм. Вы вдохновили меня, ухитрившись в ответе повторить ровно ту же ошибку. Как говорил некто Чингачгук, только бледнолицый брат..... Итак: если оператор ухитрился совершить две ошибки (то есть сначала, например, вместо кнопки "Создать диапазон" нажал кнопку "Создать точное значение", а потом еще и ввел одно число вместо двух), то он таки действительно совершил две ошибки. И даже если в структуре БД нарисовать восемь полей, ошибок меньше не станет. Потому что структура БД тут не при чем. P.S. Можно позабавляться, и даже дважды, видя как Вы ставите знак равенства между полями в таблице и полями ввода на форме. Можно предположить, откуда идет этот взгляд. Но пожалуйста, в следующий раз придумайте что-нибудь новое - смеяться над этим в третий раз будет уже скучно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 16:51 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
По этой логике если в таблице можно хранить информацию о мужчинах и женщинах, то ни в коем случае нельзя делать одно поле "пол" - это не будет оотражать "ограничений предметной области" :) надо обязательно сделать 2 поля, IsMen и IsWoman - тогда все будет корректно, и "схема данных будет отражать ограничения предметной области"? Это оригинальный взгляд, факт :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 17:00 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
> Прежде всего - кому дает. Серверу? Клиенту? Не смешно. > Итак: если оператор Если разработчик не понимает, что первична структура данных, а не гуй к ней, то это - тупой разработчик. Ничего личного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 17:03 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
> По этой логике Поделитесь травой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 17:06 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
Ну Вы же считаете, что если в таблице предполагается несколько видов сущностей - то эти сущности нельзя разграничивать значениями полей, необходимо разграничивать на уровне структуры? Иначе что означает фраза "структура не отражает ограничений предметной области" в данном примере? P.S. а Вы чего не зарегистрируетесь, кстати? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 17:13 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
> если в таблице предполагается несколько видов сущностей - то эти сущности > нельзя разграничивать значениями полей Немного не так. Канонически одна сущность - одна таблица. Если по каким-то причинам такая структура неприемлема, следует явно (на уровне структуры, на уровне типов) различать эти сущности. Но - imho никак не по значению. Причем, не только из-за возможных ошибок, куча других причин. > если в таблице можно хранить информацию о мужчинах и женщинах А от задачи, как обычно. Ну, например, в женской консультации есть база данных пациентов. И в этой же женской консультации есть какая-то софтинка отдела кадров. Вы же понимаете, что нет ничего невероятного в том, что в разных базах данных описание одной и той же сущности - человека - будет разным. ;) > не зарегистрируетесь, кстати? А зачем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 17:28 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
Если разработчик не понимает, что первична структура данных, а не гуй к ней, то это - тупой разработчик. Ничего личного. Первичен предмет автоматизации, а не структура данных :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 17:34 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
> Первичен предмет автоматизации, а не структура данных :) Т. е. Вы полагаете, процесс (в данном случае познание предмета автоматизации) - важнее результата? Хм... а Ваши заказчики об этом знают? ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 17:39 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
автор Немного не так. Канонически одна сущность - одна таблица. Если по каким-то причинам такая структура неприемлема, следует явно (на уровне структуры, на уровне типов) различать эти сущности. Но - imho никак не по значению. Причем, не только из-за возможных ошибок, куча других причин. ну так и чего же не так в примере про пол человека? выходит, на уровне структуры надо отличать сущность "мужчина" от сущности "женщина"? а не по значению какого-то поля "пол"? Ну, например, в женской консультации есть база данных пациентов. И в этой же женской консультации есть какая-то софтинка отдела кадров. Вы же понимаете, что нет ничего невероятного в том, что в разных базах данных описание одной и той же сущности - человека - будет разным. ;) Нет, погодите. Про разнесение на разные таблицы мы сейчас говорить не будем - это неинтересно, хотя бы потому что действительно очень зависит от конкретной задачи. Поговорим о различении сущностей в рамках одной таблицы на уровне структуры и на уровне значений полей - то есть то самое различие между 2 и 3 полями из исходного примера или одним полем "пол" против двух isMen и IsWoman. Вы, как я понял, считаете, что в первом случае надо разграничивать на уровне структуры, а во втором - нет. Почему так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 17:40 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
guest_20040621Не смешно. Не сомневаюсь. И, подозреваю, "не понятно" гораздо точнее опишет Ваше состояние. На всякий случай уточню, что пробел поставлен вполне осознанно. guest_20040621Если разработчик не понимает, что первична структура данных, а не гуй к ней .... В целом эта фраза не полностью раскрывает истину, но в некотором приближении я готов с ней согласиться. В свете этого можно было бы удивиться тому, что Вы завели речь об ошибках оператора, но я не вижу в этом чего-то страшного. Что дальше? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 17:48 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
Хм... а Ваши заказчики об этом знают? Знают. И очень рады, что мои модели данных не только правильные, но и отражают реальность, а не мои фантазии :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 17:50 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
> выходит, на уровне структуры надо отличать сущность "мужчина" > от сущности "женщина"? а не по значению какого-то поля "пол"? ;) ОК, давайте подробнее остановимся на мужчинах и женщинах, если Вы настаиваете. Как по-Вашего, в каких случаях женщины и мужчины должны быть выделены как отдельные сущности, без типизации? > действительно очень зависит от конкретной задачи Вы сами это сказали, прошу отметить. ;) > Поговорим о различении сущностей в рамках одной таблицы > на уровне структуры и на уровне значений полей Давайте. Моя точка зрения: разделение сущности на уровне значений - ошибка проектирования. > то самое различие между 2 и 3 полями из исходного примера или одним > полем "пол" против двух isMen и IsWoman. Вы, наверное, невнимательно читали обсуждение. ОК, аналогия с мужчинами и женщинами примерно такая: дата1 для женщины интерпретируется как дата начала менструального цикла, дата2 - как дата окончания, в то же время дата1 интерпретируется для мужчины как дата рождения. Причем, вывод о половой принадлежности человека делается на основании только дата2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 18:03 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
> мои модели данных не только правильные, но и отражают реальность, а не мои > фантазии :) Не поделитесь критерием правильности моделей и их соответствия реальности? Я по серости своей считал, что соответствие реальности в принципе невозможно, максимум достижимого - соответствие техническому заданию. ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 18:10 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
автор Как по-Вашего, в каких случаях женщины и мужчины должны быть выделены как отдельные сущности, без типизации? В тех случаях, когда сильно различаются их роли в моделируемых бизнес-процессах. автор Давайте. Моя точка зрения: разделение сущности на уровне значений - ошибка проектирования. ОК, аналогия с мужчинами и женщинами примерно такая: Стоп. Вы говорите, что разделение на уровне значений - всегда неправильно, следовательно, и в случае различия по значению поля "пол" - тоже. То есть одно поле "пол" не подходит, нужно различать на уровне структуры.Верно? как это предлагается делать? если мы предположим, что набор остальных полей у мужчин и женщин заполняется однообразно и на их основании разделить нельзя? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 18:21 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
> В тех случаях, когда сильно различаются их роли в моделируемых > бизнес-процессах. Например? > разделение на уровне значений - всегда неправильно, следовательно, > и в случае различия по значению поля "пол" - тоже. Нет, конечно. Посмотрите [2745191] на предыдущей странице. > То есть одно поле "пол" не подходит, нужно различать на уровне структуры. ;) Да ну нет же. Речь о том, что либо должна быть явная типизация (пол в Вашем примере), либо типизация на уровне структуры. Автор вопроса не предполагал явной типизации для своей структуры данных, следовательно, единственный оставшийся вариант - типизация на уровне структуры. Еще раз прочтите пример с мужчиной и женщиной - абсолютно идентичная ситуация. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 18:30 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
Кот Матроскинесли мы предположим, что набор остальных полей у мужчин и женщин заполняется однообразно и на их основании разделить нельзя?Если правильно понял контекст, то речь идет о другом. Выделяя сущности, мы идем от задачи. До тех пор, пока любой из атрибутов сущности применим к каждому экземпляру сущности, то эта сущность более абстрактна. В приведенном Вами примере, возможно, пол всего лишь атрибут более общей сущности - "человек". Как только появляется дифференциация по атрибутам, т.е., какие-либо атрибуты не применимы к каждому экземпляру, возникает повод для порождения новых сущностей. Именно в этот момент может появиться потребность разделение на 2 отдельные сущности "мужчина" и "женщина". Для первого не имеет смысла атрибут "Количество родов", для второй - "Длина члена" :) Но эти 2 сущности не отрицают существование сущности "Человек", просто, в соответствии с задачей, по причине типизации произошло деление на уровне структуры. В принципе, никто не мешает все атрибуты хранить в одной таблице, но возникают, IMHO, вполне справедливые сомнения в правильности такого подхода при проектировании РБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 18:53 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинПо этой логике если в таблице можно хранить информацию о мужчинах и женщинах, то ни в коем случае нельзя делать одно поле "пол" - это не будет оотражать "ограничений предметной области" :) надо обязательно сделать 2 поля, IsMen и IsWoman - тогда все будет корректно, и "схема данных будет отражать ограничения предметной области"? Это оригинальный взгляд, факт :) COOL пример смиялсо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 19:08 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
> Именно в этот момент может появиться потребность разделение > на 2 отдельные сущности "мужчина" и "женщина". А сразу после - появится потребность уточнить, кого именно называть женщиной, и кого - мужчиной. И, поверьте, это не слишком простая задача. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 19:19 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
я тоже обожаю переливать из пустого в порожнее... но не три же страницы форума подряд ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 19:33 |
|
||
|
Структура таблицы
|
|||
|---|---|---|---|
|
#18+
Зачем запутывать не сложный вопрос ? quest_20040621 прав - без постановки задачи не обойтись, но зачем переходить на "мужчин" и "женщин" ? Например: Номинальное (оптимальное) значение = 10 Минимальное допустимое значение = 8 Максимальное допустимое значение = 15 вполне "имеет право на жизнь". Где здесь "информация, не имеющая смысла" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 22:41 |
|
||
|
|
start [/forum/topic.php?all=1&fid=32&tid=1545217]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
174ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
76ms |
get tp. blocked users: |
1ms |
| others: | 232ms |
| total: | 526ms |
| 0 / 0 |
