|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Кот МатроскинЮзер 01примеры будут? Пожалуйста - таблица договоров, как водится, "Дата начала договора", "Дата окончания договора". Для действующих договоров, по Вашему предложению, в "Дату окончания" пишем 1900-01-01. Пишем запрос "получить договоры, закрытые на начало 2017 года" для случая с NULL и для Вашего случая, чешем в затылке на тему "Какой же получился проще?"... Да, замечательный пример, но вы и сами тут же придумаете пример, когда возможное нулл значение усложняет запрос, ведь правда? :) ... А со строками - тоже есть "плохие" случаи? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 19:18 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
antandNull умные люди специально придумали именно для того, чтобы указывать что значение неизвестно. "Умные люди" как раз утверждают, что введение понятие нулла противоречит реляционной теории. А ввели его исключительно для того, чтобы аутер джойны можно было реализовать, вот и все. Которые тоже "противоречат", :)... Об уместном месте применения нуллов я сразу в стартовом сообщении написал, почитайте. Вопрос был о другом. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 19:27 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Юзер 01, Интересно, вам хочется чтоб вас переубедили кардинально или наоборот - укрепиться в своей позиции... В наше время переубедить кого либо в чем - то практически невозможно, если он сам не захочет этого... На каждый пример из жизни можно найти кучу анти примеров и так в цикле... выше спрашивали зачем предохранители делают на оружие - так вот в одном из самых лучших пистолетов ТТ - нет предохранителя от слова совсем, оттянул затвор - стреляй... положишь в карман - может сам шмальнуть тебе в ногу, зато надежнее макара и легкий бронежилет делает на вылет... ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 21:11 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
vmagЮзер 01, Интересно, вам хочется чтоб вас переубедили кардинально или наоборот - укрепиться в своей позиции...... Нам хочется информированности. Чем удобно/неудобно использование полей данных с null-ами - примерно известно. Хорошо бы знать, чем грозит использование полей данных без null - значений. Мы не являемся упоротыми сторонниками какой-либо позиции. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 21:22 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Юзер 01Хорошо бы знать, чем грозит использование полей данных без null - значений. Придется отдельно хранить/обрабатывать признак отсутствия/наличия значения, если он нужен. (доход известен и он нулевой, доход низвестен) см. также Nullable типы в C# и Maybe в haskell. SQL несколько недоделан в том смысле что все nullable по умолчанию и нет контроля типов. В C# вот так, например Код: c# 1. 2. 3.
В SQL, насколько я помню, ошибка получится только в рантайме при вставке в NOT NULL колонку. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 22:58 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
WebSharper... Придется отдельно хранить/обрабатывать признак отсутствия/наличия значения, если он нужен. (доход известен и он нулевой, доход низвестен) ... Имхо, надуманный пример, не имеющий ничего общего с реальностью. Я могу придумать ситуацию, когда такой случай возникнет, но эта ситуация будет искусственно созданной. Если в данные не могут принимать значение null, ситуация и не возникнет, разве что как преднамеренный саботаж разработчика (против самого себя). ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 23:48 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Юзер 01WebSharper... Придется отдельно хранить/обрабатывать признак отсутствия/наличия значения, если он нужен. (доход известен и он нулевой, доход низвестен) ... Имхо, надуманный пример, не имеющий ничего общего с реальностью. Я могу придумать ситуацию, когда такой случай возникнет, но эта ситуация будет искусственно созданной. Сплошь и рядом встречается в реальной жизни. В моей работе исходные данные часто неполны: напр., в условной деревне Гадюкино указаны 67 жителей, а сколько из них мужчин/женщин — нет. Кроме null меня тут ни что не спасет. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 00:06 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Ы2Юзер 01пропущено... Имхо, надуманный пример, не имеющий ничего общего с реальностью. Я могу придумать ситуацию, когда такой случай возникнет, но эта ситуация будет искусственно созданной. Сплошь и рядом встречается в реальной жизни. В моей работе исходные данные часто неполны: напр., в условной деревне Гадюкино указаны 67 жителей, а сколько из них мужчин/женщин — нет. Кроме null меня тут ни что не спасет. Не понял, null - это баба аль мужык? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 01:10 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
чччДНе понял, null - это баба аль мужык? и то и то... null тех и null этих, - одинаково ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 01:34 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
vmagчччДНе понял, null - это баба аль мужык? и то и то... null тех и null этих, - одинаково Null тех и null этих - это все равно NULL эцих будет, с гвоздями, а не "одинаково". ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 01:47 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
WebSharperSQL несколько недоделан в том смысле что все nullable по умолчанию и нет контроля типов.Это все остальные языки недоделаны в том смысле, что типы non-nullable по умолчанию и зачастую нет нормальной поддержки наллов в фреймворках. Типичный пример - левый джойн в том же Entity Framework. Приходится изрядно извращаться, чтобы понять, вот этот ноль - это результат FirstOrDefault(), или там действительно это значение в таблице. Юзер 01Имхо, надуманный пример, не имеющий ничего общего с реальностью.Самый что ни на есть типичный. Не всегда есть возможность подобрать дефолтное значение, не конфликтующее с бизнес-логикой. Из-за этого при вашем подходе часто начинается веселье типа "на этих таблицах дефолт 0, на этих -1, а вот тут пришлось наллы использовать, потому что float". ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 03:10 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
чччДЫ2Сплошь и рядом встречается в реальной жизни. В моей работе исходные данные часто неполны: напр., в условной деревне Гадюкино указаны 67 жителей, а сколько из них мужчин/женщин — нет. Кроме null меня тут ни что не спасет. Не понял, null - это баба аль мужык? А тут и понимать нечего :) Есть три поля: всего, кол-во мужчин, кол-во женщин. А данные получены только для «всего». Если вписать нули, получится ерунда — деревня с 67 жителями, но без населения (вы же знаете, сколько будет 0+0, правда?). ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 08:56 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
постоянно приходится различать отсутствие значения и значение равное 0. Это правильная работа бизнес-логики. Тот же склад где остаток товара 0 и остаток неизвестен. Или баланс. Из-за этого извращатся приходится в случае оракла для текст полей. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 09:01 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Юзер 01"Умные люди" как раз утверждают, что введение понятие нулла противоречит реляционной теории. А ввели его исключительно для того, чтобы аутер джойны можно было реализовать, вот и все. Которые тоже "противоречат", :) Я считаю, что как раз атрибуты и сущности первичны, а уже потом следует реляционная или какая-то другая алгебра над ними. Если Вы хотите точно следовать алгебре, которая не умеет работать с неуказанным значением, то тогда и вашу предметную область надо ограничить только объектами, у которых все значения атрибутов всегда! указаны. Возьмите одну сущность, одну таблицу. Т.е. нет никаких аутер джойны и т.п. Вам надо описать поля в соответствии с предметной областью и бизнес-логикой. Значение поля в таблице может быть 1) указано или не указано - это первичный признак характеризующий значение поля, 2) если указано, то конкретное значение Т.е. значение поля описывается двумя состояниями. 1. Null 2. Not null and = значение Вы предлагаете все описать только 2 состоянием. Возможно ваша предметная область такая, что так описать возможно. Например, для поля Возраст можно использовать -1 как не указан. Но в общем случае, как я писал ранее и как Вам привели примеры другие участники, возможны конфликты, и отсюда дополнительные затраты на развитие и поддержку такой системы. Для приведенного примера возраста. Кто знает что -1 это возраст не указан? Только разработчик базы. Причем это должно быть описано в доп документации и при разработке каждого запроса к БД, при отладке и поддержке нужно это знать и помнить об этом. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 09:45 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Юзер 01"Умные люди" как раз утверждают, что введение понятие нулла противоречит реляционной теории Думаю, они говорят о противоречии в хорошем смысле этого слова. Многое в современных БД противоречит реляционной теории, или выходит за ее рамки, но это говорит скорее об ограниченности теории, чем о недостатках современных СУБД. По поводу использования null уже сказали ясно: - Лучше всего его не использовать, если задача это позволяет. Объявляйте все поля not null. Допускайте null, только если есть ясные основания. - Если все же есть основания, нужно использовать null, а не спец.константы. Потому что в общем случае и то и другое потребует специальных подходов для обработки и отображения. Например, в примере выше про "Дату закрытия договора" - если впихнуть туда 1900-01-01, то придется не только исключать это значение их диапазонов в SQL, но и уговаривать все гриды, формы и отчеты, чтобы вместо начала ХХ века они показывали пустоту. - Если какое-то значение подразумевает "многообразное отстутствие", например, "отсутствует по смыслу операции", как дата завершения еще открытого договора, или "неизвестно - временно не внесено", и всякие другие варианты, которые так и хочется закодировать волшебными -1, -2, -3 - то лучше оставить отсутствующее поле как null, а для причин отсутствия, если они уж столь важны, сделать отдельное поле - статус, со ссылкой на справочник причин. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.03.2018, 15:15 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Ennor TiegaelWebSharperSQL несколько недоделан в том смысле что все nullable по умолчанию и нет контроля типов.Это все остальные языки недоделаны в том смысле, что типы non-nullable по умолчанию Вы в курсе про billon dollar mistake? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2018, 15:48 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Ennor TiegaelПриходится изрядно извращаться, чтобы понять, вот этот ноль - это результат FirstOrDefault(), или там действительно это значение в таблице. Концептуально FirstOrDefault сделан, чтобы возвращать дефолтное значение. По идее в этом случае нужен какой-то Nullable<T> FirstOrNull<T>(Enumerable<T>) который будет возвращать какой-нибудь Nullable<Nullable<int>> для резултата аутер джойна и первый уровень nullable придет от FirstOrNull, а вложенный из джоина ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2018, 16:26 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
WebSharper, Вы не видите разницы между указателем и значением? Правда не видите, или просто пытаетесь так криво троллить? WebSharperПо идееПо идее оно могло бы работать так же гладко и естественно, как оно делает это в SQL. Но не делает этого, и скорее всего никогда не будет этого делать, т.к. NULL - это доп. бит к переменной. И если в таблице можно складывать эти биты, изрядно экономя место (маски 8 столбцов = 1 байт), то для одиночной переменной придется выделять целый байт под этот бит. В результате - О УЖАС!!!!!11111одинодинодин - перерасход памяти! Мы все умрем немедленно от этого перерасхода, очевидно же. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2018, 03:38 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
WebSharper Код: c# 1. 2. 3.
гм.. Код: c# 1.
уже без ошибок. SQL по сути делает тоже самое, только без необходимости подставлять значение по умолчанию. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2018, 06:34 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
hVostt Код: c# 1.
уже без ошибок. Код: c# 1. 2.
SQL по сути делает тоже самое, только без необходимости подставлять значение по умолчанию. Именно это и неправильно. В SQL нет возможности сказать "здесь я ожидаю не nullable" и поэтому на каждом этапе нужно думать о вохможности null вместо того, чтобы подумать об этом только при получении значения. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2018, 09:42 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Ennor TiegaelWebSharper, Вы не видите разницы между указателем и значением? Правда не видите, или просто пытаетесь так криво троллить? Я вообще не вижу в данной задаче чего-то харакетрного именно для указателей. (Если вы считаете, что billion dollar mistake характерно только для указателей попробуйте подумать, какие именно свойства указателей к этому приводят и почему этого нет у других nullable values) WebSharperПо идееПо идее оно могло бы работать так же гладко и естественно, как оно делает это в SQL. Но не делает этого, и скорее всего никогда не будет этого делать, т.к. NULL - это доп. бит к переменной. И если в таблице можно складывать эти биты, изрядно экономя место (маски 8 столбцов = 1 байт), то для одиночной переменной придется выделять целый байт под этот бит. В результате - О УЖАС!!!!!11111одинодинодин - перерасход памяти! Мы все умрем немедленно от этого перерасхода, очевидно же. Тут вообще дело не в памяти. Скорее дело в экономии внимания человека - в возожности ограничить области в программе где может быть null от тех где не может быть и думать о возможности null только в тех местах где может быть. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2018, 09:52 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
WebSharperИменно это и неправильно. В SQL нет возможности сказать "здесь я ожидаю не nullable" и поэтому на каждом этапе нужно думать о вохможности null вместо того, чтобы подумать об этом только при получении значения. Это как это нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2018, 10:12 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
hVosttЭто как это нет? Упс. Тут я не подумал. Есть, конечно. В колонках таблиц, например. Интересно, как это работает для промежуточных вычислений. Вот такой код вообще без ошибок на TSQL выдает NULL Код: sql 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2018, 10:32 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
WebSharperУпс. Тут я не подумал. Есть, конечно. В колонках таблиц, например. Интересно, как это работает для промежуточных вычислений. Вот такой код вообще без ошибок на TSQL выдает NULL я большой противник «промежуточных вычислений» (т.е. бизнес-логики) в СУБД, поэтому меня это не парит )) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2018, 20:59 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
hVosttя большой противник «промежуточных вычислений» (т.е. бизнес-логики) в СУБД, поэтому меня это не парит ))А как Вы делаете сложный отчет с 50 колонками из 5-6 источников ? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2018, 10:41 |
|
|
start [/forum/topic.php?fid=32&msg=39609464&tid=1540052]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
131ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
64ms |
get tp. blocked users: |
2ms |
others: | 235ms |
total: | 479ms |
0 / 0 |