|
|
|
Альтернатива NULL длменам в таблице
|
|||
|---|---|---|---|
|
#18+
Встал вопрос по доменам в таблице. Например Клиент указывает Дату рождения. Он может не указывать ее - вопрос, что лучше хранить NULL или, например DateTime.MinValue ? по теории Реляционных баз вроде как если у таблицы есть NULL домены - это плохо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2010, 10:11 |
|
||
|
Альтернатива NULL длменам в таблице
|
|||
|---|---|---|---|
|
#18+
Именно поэтому их и придумали - чтобы с трудностями бороться С уважением, Naf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2010, 10:47 |
|
||
|
Альтернатива NULL длменам в таблице
|
|||
|---|---|---|---|
|
#18+
ишо wrote: > Встал вопрос по доменам в таблице. Например Клиент указывает Дату > рождения. Он может не указывать ее - вопрос, что лучше хранить NULL или, > например DateTime.MinValue ? NULL однозначно. Никаких "специальных значений" в БД. > по теории Реляционных баз вроде как если у таблицы есть NULL домены - > это плохо Нет, никто такого не говорит. Это ты придумал. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2010, 10:57 |
|
||
|
Альтернатива NULL длменам в таблице
|
|||
|---|---|---|---|
|
#18+
ишоВстал вопрос по доменам в таблице. Например Клиент указывает Дату рождения. Он может не указывать ее - вопрос, что лучше хранить NULL или, например DateTime.MinValue ? Хранить в БД естественно NULL...так как именно эта величина означает, что значение не определено. ишо по теории Реляционных баз вроде как если у таблицы есть NULL домены - это плохо Это Вы выдумываете.....:-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2010, 12:43 |
|
||
|
Альтернатива NULL длменам в таблице
|
|||
|---|---|---|---|
|
#18+
по поводу авторпо теории Реляционных баз вроде как если у таблицы есть NULL домены - это плохо а зачем тогда нужна борьба с избыточностью данных - можно же всё в одну таблицу запихнуть тогда ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2010, 14:57 |
|
||
|
Альтернатива NULL длменам в таблице
|
|||
|---|---|---|---|
|
#18+
Например для периодов КМК имеет смысл +/- бесконечность кодировать реальными запредельными в смысловом отношении датами например 31.12.2999, 01.01.1900 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2010, 16:02 |
|
||
|
Альтернатива NULL длменам в таблице
|
|||
|---|---|---|---|
|
#18+
_kykyнапример 31.12.2999, 01.01.1900 вообще-то еще есть те, кто родился до 1900 года. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2010, 11:13 |
|
||
|
Альтернатива NULL длменам в таблице
|
|||
|---|---|---|---|
|
#18+
ишо по теории Реляционных баз вроде как если у таблицы есть NULL домены - это плохо Ну это хуже чем када их нет. Они влияют на запросы. Пишущий должен знать про их. Если их заменить левыми не реальными, то пишущему нуно еще больше знать про эту особенность. На NULL то он может проверить, если осторожный чел. А так ему больше нуно проверять, потом выяснять, шо там такое: ошибка или че. В идеале какда все данные в таблах определенгы и известны. Без NULL двузначная логика с NULL, в СУБД типа Оракла трехзначная. А в общем может быть и четырехзначной, но там типа NULL делится на не определено и не известно. Для основных полей луче избегать NULL. Но скорее, всего NULL луче чем левые значения. Тем более, что в запросах NULL моно заменить на левое, если нуно. А если они в табле, то моно слишком поздно узнать про истинный смысл этих левых значений. =Lucky=Хранить в БД естественно NULL...так как именно эта величина означает, что значение не определено. А если не известно? Ить дата рождения, то определена (она имеет смысл), но типа не известна тому кто вводит данные. Это, скорей всего, остутствие величины. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2010, 14:31 |
|
||
|
Альтернатива NULL длменам в таблице
|
|||
|---|---|---|---|
|
#18+
ишопо теории Реляционных баз вроде как если у таблицы есть NULL домены - это плохо Ну версий РМ много, и в догматической интерпретации действительно считается что NULLи это зло. Проблема NULLей была создана во-многом искусственно на теоретическом уровне, а на практике да и в хорошей теории ее нет. Нули не только не зло, а полезная и в чем-то необходимая часть модели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2010, 18:37 |
|
||
|
Альтернатива NULL длменам в таблице
|
|||
|---|---|---|---|
|
#18+
ишоВстал вопрос по доменам в таблице. Например Клиент указывает Дату рождения. Он может не указывать ее - вопрос, что лучше хранить NULL или, например DateTime.MinValue ? по теории Реляционных баз вроде как если у таблицы есть NULL домены - это плохо Странный вопрос, как и все последующее обсуждение:) Лучше не хранить NULL, и лучше не хранить никаких других значений:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2010, 20:38 |
|
||
|
Альтернатива NULL длменам в таблице
|
|||
|---|---|---|---|
|
#18+
_kykyНапример для периодов КМК имеет смысл +/- бесконечность кодировать реальными запредельными в смысловом отношении датами например 31.12.2999, 01.01.1900 Для периодов в данном случае смысл не "не задано", а +бесконечность или -бесконечность ( хотя - бесконечность реже встречается, начало периода, обычно известно) и именно для периодов на практике чаще всего вводят какое - нить константное значение для +-бесконечностей... для случаев "не задано" (неизвестно) на практике принято использовать NULL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2010, 16:35 |
|
||
|
Альтернатива NULL длменам в таблице
|
|||
|---|---|---|---|
|
#18+
ишочто лучше хранить NULL или, например DateTime.MinValue ? Я стараюсь хранить Null, но был один заказчик приказавший хранить в таком случае свою дату рождения (при чем последсвия его не волновали). Мотивировал он это весьма странно - типа если БД и программу украдут - то там мы докажем что она наша. У каждого свои тараканы (с) Как сказали так и сделал, но помню до сих пор ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2010, 21:59 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=36560117&tid=1542756]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
156ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 208ms |
| total: | 460ms |
| 0 / 0 |
