|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
База, в в ней таблички. Каждая табличка имеет суррогатный ключ типа Int64. Таблички связаны между собой с помощью FK - ограничений. Каждое поле, ссылающееся по FK на другую табличку, может быть как "nullable", так и "not null", в зависимости от особенностей FK - связи. Тут удобство null-ов не вызывает сомнений. С полями, реализующими FK-связи, вопросов нет. ... А еще есть поля, несущие уже "кондовую" смысловую нагрузку: Фамилия, Стоимость, Адрес... Какой смысл разрешать для таких полей значение null? Ну, можно придумать. Например, поле "Дата начала строительство". Пока оно null, строительство и не началось. Но ведь можно для этого задействовать какую-либо "волшебную константу", какой-нибудь Код: sql 1.
... Для строк использовать значение "пустая строка", для чисел - "0". Null, конечно, сам по себе является такой "волшебной константой". Но ведь значение 0 (или "пустая строка") можно использовать в запросах наравне с остальными значениями, а с null-ами приходится кочевряжиться! Вот и вопрос: есть ли смысл для "бизнес" - значений использовать типы с ограничениями Код: sql 1.
? Не создаст ли сие каких-либо неудобств в дальнейшем? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 00:08 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Юзер 01Не создаст ли сие каких-либо неудобств в дальнейшем?Нулы в базе не хранятся, а значит экономят место, в отличие от волшебных констант. Но это еще полбеды. Потом эти константы полезут юзерам на экран. Фронтэндщикам геморой обеспечен. Нужно будет кастить все "это" в пустые значения. Вообщем, вас найдут и будут бить долго)) И фронт и бэк. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 02:57 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Это религиозный вопрос ) Например, в Dynamics AX во всех таблицах вместо null дат используется значение 1900-01-01 00:00:00.000. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 03:11 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 03:19 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Юзер 01Но ведь значение 0 (или "пустая строка") можно использовать в запросах наравне с остальными значениями, а с null-ами приходится кочевряжиться! Собственно в этом и смысл. Вам придётся учесть отсутствие значений, значит меньше возможностей натупить. И FK тоже для этого. Вам приходится учитывать наличие связей. Это всё делается от человеческих ошибок. Если бы человек не ошибался никогда, ничего этого было бы не нужно. Никаких констрейтов, связей, NULL-ов и прочего :) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 08:52 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
bideveloperЭто религиозный вопрос ) + Юзер 01Для строк использовать значение "пустая строка", для чисел - "0". Ничего плохого не вижу в том, что это будут значения по умолчанию, пока нет записи - ничего нигде не хранится, - это всего лишь значения по умолчанию, при добавлении записи пустая строка никого не испугает, а её и ноль и проще контролировать при вводе данных и бывает, что это и есть потом реальное значение... Если сам потом будешь дописывать лицо - то вообще делай как тебе удобнее и не парься... ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 08:54 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Relic HunterНулы в базе не хранятся, а значит экономят место, в отличие от волшебных констант.Пустая строка varchar тоже не хранится. А числа - наверняка даже когда они null также хранятся. Впрочем, какая разница, дело разве в этом? Relic Hunter...Нужно будет кастить все "это" в пустые значения...А для чего нужно пустую строку (или нули в числах) кастить в пустое значение? Например. Структуры данных на клиентской стороне не предусматривают null значений, разве что специальные, для совместимости с null-данными в БД. Relic Hunter...Вообщем, вас найдут и будут бить долго)) И фронт и бэк.Так в чем проблемы-то, конкретно? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 08:57 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
vmag...Если сам потом будешь дописывать лицо - то вообще делай как тебе удобнее и не парься... Я вот и спрашиваю - может, в чем-то подвох? Не зря ведь народ отстаивает важность null-ов. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 09:02 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
hVostt... И FK тоже для этого. Вам приходится учитывать наличие связей. Это всё делается от человеческих ошибок. Если бы человек не ошибался никогда, ничего этого было бы не нужно. Никаких констрейтов, связей, NULL-ов и прочего :)Про nullы в FK я сразу написал, в стартовом сообщении. О чем тут еще говорить? hVostt...Собственно в этом и смысл. Вам придётся учесть отсутствие значений, значит меньше возможностей натупить...Что за "смысл"? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 09:09 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Юзер 01, NULL обозначает отсутствующее или неизвестное значение. Это не ноль (0), и не пустая строка (""), это вообще не значение. Вот и весь смысл. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 09:59 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Юзер 01Так в чем проблемы-то, конкретно?Наверняка возникнет путаница и где-нибудь поедут результаты. Не верите? Тогда не используйте NULL и проверите на себе ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 10:06 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Нулл в некот. СУБД не хранится в индексах, поэтому если нужно часто искать по поле = нулл, то это создаст ряд неудобств. Оба варианта имеют "+" и "-". ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 10:39 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
skyANAЮзер 01, NULL обозначает отсутствующее или неизвестное значение. Это не ноль (0), и не пустая строка (""), это вообще не значение. Вот и весь смысл. А Волга впадает в Каспийское море. К чему эта банальная сентенция? LSVНулл в некот. СУБД не хранится в индексах, поэтому если нужно часто искать по поле = нулл, то это создаст ряд неудобств. Оба варианта имеют "+" и "-". 1.Если null не использовать - какие могут быть неудобства с индексами? 2. Какие именно минусы, можно пару примеров? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 11:17 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
...удивительное желание отвечать на незаданные вопросы. ТС спрашивает о смысле использования значений null в полях, не являющихся ключевыми. Ему начинают отвечать копипастами типа "потом пожалеешь/намучаешься" или "нулл это ...". А почему, зачем - а вот так. Привыкли мы. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 11:22 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Юзер 01hVostt...Собственно в этом и смысл. Вам придётся учесть отсутствие значений, значит меньше возможностей натупить...Что за "смысл"? Вы перечитайте моё сообщение. Почитайте про теорию искусственных ограничений в дизайне. Если совсем туго с мышлением и не доходит, ещё задайте вопрос, за каких хреном в оружии приделывают предохранители. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 11:32 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
чччД...удивительное желание отвечать на незаданные вопросы. ТС спрашивает о смысле использования значений null в полях, не являющихся ключевыми. Ему начинают отвечать копипастами типа "потом пожалеешь/намучаешься" или "нулл это ...". Не выдумывайте глупости. Отвечают строго по делу. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 11:39 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
чччДskyANAЮзер 01, NULL обозначает отсутствующее или неизвестное значение. Это не ноль (0), и не пустая строка (""), это вообще не значение. Вот и весь смысл. А Волга впадает в Каспийское море. К чему эта банальная сентенция? Если вам тяжело даётся банальное мышление и логика, то уже никакие сентенции тут не помогут. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 11:41 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
чччД1.Если null не использовать - какие могут быть неудобства с индексами? 2. Какие именно минусы, можно пару примеров?яннп. Изъясняйся точнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 11:53 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
чччДskyANAЮзер 01, NULL обозначает отсутствующее или неизвестное значение. Это не ноль (0), и не пустая строка (""), это вообще не значение. Вот и весь смысл. А Волга впадает в Каспийское море. К чему эта банальная сентенция? Именно к тому, что всё банально. Не надо искать тайный смысл и создавать тему для срача на форуме. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 12:09 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Если пользователь не указал свой возраст, потому как женщина, то не надо делать из него младенца ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 12:13 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Юзер 01Но ведь можно для этого задействовать какую-либо "волшебную константу", какой-нибудь cast(0 as date). .... можно использовать в запросах наравне с остальными значениями, а с null-ами приходится кочевряжиться! Да, это популярная идея. Чтобы вылечиться от неё, нужно устроиться работать на сопровождение продукта, созданного подобными гениями, и на своей шкуре ощутить, какое количество идиотских проблем вырастает из этих "некочевряжащихся" волшебных констант, и вдруг однажды осознать, что будь на их месте null-ы - такого бы не случилось. Тогда сразу становится понятно, зачем они нужны и почему "кочевряжиться" с ними нужно именно так. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 16:12 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
softwarer, примеры будут? Или неприятие связано с особенностями конкретной СУБД? В любимом оракле нулл и пустая строка - одно и то же. Но не совсем. Какого-то диавола в оракле length('') оказывается нуллом. И сравнение с пустой строкой тоже нулл. Ну, оракл он такой, своя религия. Оставим его, тут уже ничего не исправить. Ну вот кому конкретно станет плохо, когда length('') станет равен 0? Или AVG() станет возвращать действительно средний уровень дохода в семье именно на человека, а не средний уровень дохода только среди получающих этот доход? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 18:07 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Юзер 01 примеры будут? Пожалуйста - таблица договоров, как водится, "Дата начала договора", "Дата окончания договора". Для действующих договоров, по Вашему предложению, в "Дату окончания" пишем 1900-01-01. Пишем запрос "получить договоры, закрытые на начало 2017 года" для случая с NULL и для Вашего случая, чешем в затылке на тему "Какой же получился проще?". Или для дат Вы захотите использовать вместо NULL уже 2 константы - Очень Большую и Очень Маленькую? И каждый раз при написании запроса гадать - А какую же из констант в поле писали раньше? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 18:22 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Кот Матроскин Или для дат Вы захотите использовать вместо NULL уже 2 константы - Очень Большую и Очень Маленькую?Кстати, в PostgreSQL для дат так и есть, "infinity" и "-infinity", иногда очень удобно. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 18:30 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Юзер 01, skyANA все точно описал. При проектировании базы Вы на 100% не можете заложить все нужные константы на все случаи жизни для всех разных атрибутов всех разных сущностей. Может конечно и сможете, но это потребует умопомрачительной работы, анализа и знания данных предметной области, причем с учетом перспективы будущего. Т.е. есть большой шанс нарваться на то, что Ваша константа в один прекрасный момент вдруг станет не пустым значением для предметной области и бизнес-логики, со всеми вытекающими последствиями для системы. Null умные люди специально придумали именно для того, чтобы указывать что значение неизвестно. Это значение ни с чем не пересечется, оно не равно никакому другому значению в предметной области. Это как 0 - специальное число, которое до поры до времени числом не считали. Пока есть что считать, ноль нас мало интересует. Но чтобы обозначит как-то, что считать нечего, придумали 0. А в математ теориях это уже полноправное число и без него уже никак. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.03.2018, 19:00 |
|
Проектирование: есть ли смысл разрешать 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 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
LSVhVosttя большой противник «промежуточных вычислений» (т.е. бизнес-логики) в СУБД, поэтому меня это не парит ))А как Вы делаете сложный отчет с 50 колонками из 5-6 источников ? Человек страшно далек от BI, OLAP и прочих DWH ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2018, 11:23 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Ivan DurakLSVпропущено... А как Вы делаете сложный отчет с 50 колонками из 5-6 источников ? Человек страшно далек от BI, OLAP и прочих DWHЭто в чей адрес реплика ? Если в системе просто нет ОЛАП/БИ/ДВХ (нецелесообразно). А неск. сложных отчетов есть. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2018, 13:17 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
LSVhVosttя большой противник «промежуточных вычислений» (т.е. бизнес-логики) в СУБД, поэтому меня это не парит ))А как Вы делаете сложный отчет с 50 колонками из 5-6 источников ? у нас дофига отчётов, где колонок и по-более и источников по-более, и это ещё с учётом исторических данных и данных, полученных из внешних источников. удивить 50-ю колонками, не получится. да, без логиги в БД всё прекрасно получается делать. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2018, 15:08 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Ivan DurakЧеловек страшно далек от BI, OLAP и прочих DWH т.е. вы прямо утверждаете, что BI, OLAP и прочие DWH, без логики в БД невозможен или нормальной жизни нет? а вы точно разработчик, а не начитались каких-то терминов с хабра? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2018, 15:10 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
hVostt... удивить 50-ю колонками, не получится. да, без логиги в БД всё прекрасно получается делать. Что-то да, действительно непонятно, при чем тут логика в БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2018, 16:58 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Считаю null полноценным определением "ничего, пусто". А ноль (0) всего лишь цифра. Как и все остальные. Поэтому заменять им "ничего" не стоит. На уровне микросхем используются три значения - 0, 1 и "ничего" в виде разного напряжения или его отсутствия. Теоретически микросхемный "0" может иметь напряжение 0-1 вольт, но 0 практически не используется, так как это означало бы сплошное обнуление при отсутствии питания. Отсутствие напряжения, это не "0", а "ничего" (null). Так и в "бизнес-логике" считаю употребление null вполне оправданным. "Если null существует, значит это кому-то нужно". ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2018, 17:41 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
hVosttя большой противник «промежуточных вычислений» (т.е. бизнес-логики) в СУБД, поэтому меня это не парит )) A+B это уже промежуточные высичления. К тому же надо как-то сопрягаться с бизнеслогикой :) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2018, 19:22 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Смешной топик. Впрочем, другим он не мог быть, так как стартовал с ухмылочек. Юзер 01 ...есть ли смысл для "бизнес" - значений... Проблема со смыслами не в том, чтобы их куда-то "вложить", а в том, чтобы после такого "вложения" использовать полученный смысл непротиворечиво со всеми предыдущими смыслами, существовавшими до такого "вложения". Юзер 01Ну вот кому конкретно станет плохо, когда length('') станет равен 0? В ту же секунду станет плохо каждому , кто использует конкатенацию в такой системе. Потому что, при таком раскладе, конкатенаций, внезапно, должно образоваться две . Иначе нет смысла в раличении Null и ''. А length, возращающий ноль применительно к null - нонсенс. То есть, буквально, length('') внезапно ставший возвращать ноль, означает, что старую математику, обслуживавшую тип данных, из коробочки вынули, и новую туда поставили, не обращая внимания на использующий её клиентский код. В переводе на русский - системообразующий код может меняться. Но правильно он меняется только путем замены самой системы, и, автоматически, вместе с заменой (переписыванием) всей базы использующего возможности системы клиентского кода. Юзер 01Или AVG() станет возвращать действительно средний уровень дохода в семье именно на человека, а не средний уровень дохода только среди получающих этот доход? Это псевдовопрос, то есть, не вопрос. Используя Avg, таким, каков он есть сейчас, вы можете решить обе задачи. А тот, который вам померещился, может решать только одну из них. Юзер 01Вот и вопрос: есть ли смысл для "бизнес" - значений использовать типы с ограничениями not null & (devault value = 0|'') ? Не создаст ли сие каких-либо неудобств в дальнейшем? Тут божий дар и яичница. Божий дар - это "бизнес-значения", а яичница разведена в значениях по умолчанию. Исходный смысл значений по умолчанию состоит именно в представлении "естественных" бизнес-значений. Именно "бизнес-значений". Так, если у вас есть пара полей с датой, для одного из них - даты начала, чаще всего естественно объявить ограничение not Null, а для второго - дата завершения, может возникать естественное значение по умолчанию, сорта - Date '9999-12-31'. Это значение - вполне себе бизнес значение, никаким специальным образом не отличимое ни от какого другого пригодного для бизнеса значения даты, допустимого для указания в этом поле. И не требующее специальной математики для своей интерпретации. Имеющая физический смысл "актуальной бесконечности" времени действия. Существо вашего предложения здесь сводится к тому, чтобы в качестве значений по умолчанию указывать именно "не-бизнес-значения". Специальные стоп-значения, не имеющие бизнес-смысла, и необходимые только для имитации "отказа" от null. Между тем: a) это не имеет никакого отношения к "отказу от null". Это замена "универсального" null на специфически типизированный - "не значение" для конкретного домена. Поэтому б) по смыслу это действие отлично от заявления значения по умолчанию. Это заявление специфического null для конкретного типа данных. То есть это просто другое свойство. И для самого поля базовой таблицы оно будет отсутствовать почти во всех системах. Вообще говоря, это свойство не самого поля, а типа данных, хранимого в этом поле. Ведет это к следующему: в) техника такого сорта обязывает вас, по крайней мере для себя, научиться явно отличать (на уровне предоставляемой вами библиотечной математики) - где вы задействуете значение по умолчанию именно для бизнес-значения, а где для представления такого "типизированного для конкретного поля Null". По существу - вы сначала умножаете сущности, а потом перемешиваете их, путем использования одного и того же sql-интерфейса. г) сам перемешал, самому и расхлебывать. Т.е. ответственность за интерпретацию, совместимость и непротиворечивость использования - целиком ваша. Вот есть у вас две таблицы T1 и T2. И в каждой по числовому полю - T1.P1 и T2.P2 И для T1.P1 естественным "не значением", решили вы, является ноль, а для T2.P2 - минус единица. Затем вы собственными руками рисуете union на этих двух таблицах: Select P1 as Eternity From T1 Union All Select P2 From T2 Теперь вы бог "своей системы", и никто, кроме вас не знает, каким должно оказаться "не значение" для свежеполученного поля Eternity Юзер 01Не создаст ли сие каких-либо неудобств в дальнейшем? Для богов не существует понятия "неудобство". Ну, просто иногда чуть-чуть не хватает времени, чтобы сложить слово "Вечность". Это не является неудобством. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2018, 19:28 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Юзер 01hVostt... удивить 50-ю колонками, не получится. да, без логиги в БД всё прекрасно получается делать. Что-то да, действительно непонятно, при чем тут логика в БД. непонятно к чему этот комментарий ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2018, 20:22 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Юзер 01Ну, можно придумать. Например, поле "Дата начала строительство". Пока оно null, строительство и не началось. Но ведь можно для этого задействовать какую-либо "волшебную константу", какой-нибудь? любой, у кого есть реальный опыт работы с базами данных всегда использует именно nulls для подобного рода вещей, никаких констант ... |
|||
:
Нравится:
Не нравится:
|
|||
09.03.2018, 10:56 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
stenfordЮзер 01Ну, можно придумать. Например, поле "Дата начала строительство". Пока оно null, строительство и не началось. Но ведь можно для этого задействовать какую-либо "волшебную константу", какой-нибудь?любой, у кого есть реальный опыт работы с базами данных всегда использует именно nulls для подобного рода вещей, никаких констант"любой", "все знают" и пр. - типичные, довольно грубые приёмы демагогических и манипулятивных обобщений... Кароч низачод... Вы банальный 1С чтоле не видели ? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2018, 23:41 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Юзер 01База, в в ней таблички. Каждая табличка имеет суррогатный ключ типа Int64. Таблички связаны между собой с помощью FK - ограничений. Каждое поле, ссылающееся по FK на другую табличку, может быть как "nullable", так и "not null", в зависимости от особенностей FK - связи. Тут удобство null-ов не вызывает сомнений. С полями, реализующими FK-связи, вопросов нет. ... А еще есть поля, несущие уже "кондовую" смысловую нагрузку: Фамилия, Стоимость, Адрес... Какой смысл разрешать для таких полей значение null? Ну, можно придумать. Например, поле "Дата начала строительство". Пока оно null, строительство и не началось. Но ведь можно для этого задействовать какую-либо "волшебную константу", какой-нибудь Код: sql 1.
... Для строк использовать значение "пустая строка", для чисел - "0". Null, конечно, сам по себе является такой "волшебной константой". Но ведь значение 0 (или "пустая строка") можно использовать в запросах наравне с остальными значениями, а с null-ами приходится кочевряжиться! Вот и вопрос: есть ли смысл для "бизнес" - значений использовать типы с ограничениями Код: sql 1.
? Не создаст ли сие каких-либо неудобств в дальнейшем? Вы с самого начала ввели себя в заблуждение. "Кондовые" поля - это результат денормализации. Фамилия, например - это самостоятельный тип сущности, имеющий свои свойства (такие, как происхождение, например). Так что - "не вызывает сомнений":) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2018, 16:55 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
Те, кто говорят что NULL усложняет запросы, просто не могут принять, что кроме двузначной логики есть еще и трехзначная, и придется ее выучить. Разучивать различные фреймворки не лень, а логику лень. Да взять хотя бы обычный битовый признак: 0 - задание завершилось не успешно 1 - задание завершилось успешно NULL - завершение задания еще не известно.. оно или выполняется в данный момент или еще не началось А теперь в игру включается NOT NOT 0 = 1 - отрицаем, что задание завершилось не успешно, получаем успешно NOT 1 = 0 - отрицаем, что задание завершилось успешно, получаем не успешно NOT NULL = NULL - отрицаем непонятное состояние, получаем непонятное состояние Пример надуманный, но показывает суть NULL-величин, кстати NULL это обозначение отсутствующего значения, а не величины. Просто принято говорить как значение, ради простоты общения и обозначения. Вообще правильно говорить NULL-маркер. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.04.2018, 22:01 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
WebSharperhVosttя большой противник «промежуточных вычислений» (т.е. бизнес-логики) в СУБД, поэтому меня это не парит )) A+B это уже промежуточные высичления. К тому же надо как-то сопрягаться с бизнеслогикой :) Если речь только о чтении, то допустимо такие "приложения" делать. Но, в целом, любая "логика" в приложении делает такую информационную систему не системой БД. Тогда это еще можно как-то обсуждать, но, только не в разделе "Проектирование БД", потому что приложение БД, которое что-то вычисляет - это не приложение БД, или ПО очень низкого качества. Это просто основной закон теории БД:) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.04.2018, 11:35 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
X-CiteТе, кто говорят что NULL усложняет запросы, просто не могут принять, что кроме двузначной логики есть еще и трехзначная, и придется ее выучить. Разучивать различные фреймворки не лень, а логику лень.Если бы она ещё была в стандартном SQL, эта логика NULL-ов... всё равно придётся исключения запоминать (а они сделаны исключительно для удобства в типичных случаях, похоже). ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2018, 20:51 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
БредятинаЕсли речь только о чтении, то допустимо такие "приложения" делать. Но, в целом, любая "логика" в приложении делает такую информационную систему не системой БД. Тогда это еще можно как-то обсуждать, но, только не в разделе "Проектирование БД", потому что приложение БД, которое что-то вычисляет - это не приложение БД, или ПО очень низкого качества. Это просто основной закон теории БД:) Поздравляю с грибным трипом! ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2018, 21:32 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
БредятинаТогда это еще можно как-то обсуждать, но, только не в разделе "Проектирование БД", потому что приложение БД, которое что-то вычисляет - это не приложение БД, или ПО очень низкого качества. Что такое "приложение БД"? Есть язык SQL в нем есть вычисления. A+B это уже вычисление. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2018, 09:19 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
hVosttБредятинаЕсли речь только о чтении, то допустимо такие "приложения" делать. Но, в целом, любая "логика" в приложении делает такую информационную систему не системой БД. Тогда это еще можно как-то обсуждать, но, только не в разделе "Проектирование БД", потому что приложение БД, которое что-то вычисляет - это не приложение БД, или ПО очень низкого качества. Это просто основной закон теории БД:) Поздравляю с грибным трипом! Бетховен никогда не был в Уфе. И потом - какое отношение имеет Бетховен к приложениям БД? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2018, 15:06 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
WebSharperБредятинаТогда это еще можно как-то обсуждать, но, только не в разделе "Проектирование БД", потому что приложение БД, которое что-то вычисляет - это не приложение БД, или ПО очень низкого качества. Что такое "приложение БД"? Есть язык SQL в нем есть вычисления. A+B это уже вычисление. На стороне БД? Очень хорошо, что нет никакого приложения БД. Я полагал, что у hVostt, которому Вы написали, оно есть:) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2018, 15:09 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
БредятинаБетховен никогда не был в Уфе. И потом - какое отношение имеет Бетховен к приложениям БД? Если не получается понятным для людей языком излагать мысли, можно найти себя на каком-нибудь другом поприще. У вас как раз это не получается. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2018, 22:12 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
hVosttБредятинаБетховен никогда не был в Уфе. И потом - какое отношение имеет Бетховен к приложениям БД? Если не получается понятным для людей языком излагать мысли, можно найти себя на каком-нибудь другом поприще. У вас как раз это не получается. Ты зачем это пишешь персонажу с ником Бредятина? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2018, 07:03 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
skyANAТы зачем это пишешь персонажу с ником Бредятина? Ну я глянул в профиль, вроде не ПТ-шник же ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2018, 09:39 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
БредятинаWebSharperпропущено... A+B это уже вычисление. На стороне БД? На стороне СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2018, 12:03 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
hVosttБредятинаБетховен никогда не был в Уфе. И потом - какое отношение имеет Бетховен к приложениям БД? Если не получается понятным для людей языком излагать мысли, можно найти себя на каком-нибудь другом поприще. У вас как раз это не получается. 1) Что значит "для людей"? Это профессиональный форум. Если Вы не разбираетесь в теории и проектировании БД (а это - факт), то, разумеется, Вы не все можете понять. 2) Если я что-то не понимаю, то считаю, что дело исключительно во мне, а не в том, кто объясняет, и столько раз переспрошу, сколько нужно для того, чтобы понять. Если этот вопрос меня интересует, разумеется. 3) Вероятно, Вас БД не настолько интересуют, чтобы в них разбираться:) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2018, 16:04 |
|
Проектирование: есть ли смысл разрешать null-значения для "бизнес-данных"?
|
|||
---|---|---|---|
#18+
skyANAhVosttпропущено... Если не получается понятным для людей языком излагать мысли, можно найти себя на каком-нибудь другом поприще. У вас как раз это не получается. Ты зачем это пишешь персонажу с ником Бредятина? А Вы зачем упоминаете персонаж с ником Бредятина?:) Чувствуете, все-таки, ограниченность своих знаний в области БД:)? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2018, 16:05 |
|
|
start [/forum/topic.php?all=1&fid=32&tid=1540052]: |
0ms |
get settings: |
11ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
198ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
84ms |
get tp. blocked users: |
2ms |
others: | 243ms |
total: | 573ms |
0 / 0 |