|
|
|
Структура таблицы
|
|||
|---|---|---|---|
|
#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 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=33775540&tid=1545217]: |
0ms |
get settings: |
5ms |
get forum list: |
17ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
138ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 212ms |
| total: | 424ms |
| 0 / 0 |
