Реальное значение NULL в СУБД

← →
Германн © (2010-11-15 01:54) [0]

Есть ли какое-то более-менее принятое правило о том, что реально записывается в ячейку памяти в БД если значение поля NULL?
Неважно какой тип имеет это поле, но пока интересуют поля целочисленного типа.
P.S. Разрабатываю структуру БД для своей программы, но пока это будет только файл (набор файлов) конфигурации. В будущем, если и ишак и эмир будут живы, будет разрабатываться (мной или не мной) платное ПО. Так что хотелось бы облегчить перенос "псевдоБД" в настоящую СУБД.

← →
sniknik © (2010-11-15 08:06) [1]

есть очень четкое правило, при NULL в ячейку памяти БД не записывается ничего... значения нет, есть только указатель, без того на что он указывает, и его реальное значение неважно, может там 0 может -1, все одно определить его "напрямую" нельзя, только через ключевое слово NULL.

и кстати, если подумать, значение "указателя" может быть и не указателем, в зависимости от типа, может если поле не переменной длинны и значение хранится непосредственно в таблице, то NULL может быть просто признаком..., вне поля (иначе пришлось бы вводить ограничение на 1 значение из диапазона типа)

← →
_Юрий (2010-11-15 09:06) [2]

> облегчить перенос "псевдоБД" в настоящую СУБД.

Облегчать перенос нужно с помощью общих интерфейсов доступа к данным, а не с помощью одинаковости физической структуры хранения.
Вообще, то, как именно реализован NULL, должно быть скрыто от клиенского кода.

← →
Anatoly Podgoretsky © (2010-11-15 09:07) [3]

> Германн (15.11.2010 01:54:00) [0]

Не твое дело, а записан там NULL

← →
Anatoly Podgoretsky © (2010-11-15 09:11) [4]

> sniknik (15.11.2010 08:06:01) [1]

Может быть битом, может быть байтом, может еще чем угодно быть, так что
гадание лишнее.

← →
Медвежонок Пятачок © (2010-11-15 09:32) [5]

в ячейку памяти БД не записывается ничего... значения нет

Да ладно. Так не бывает.
Пишется либо флаг (не в само поле) либо в поле пишется "спец значение" , говорящее что там нулл.

← →
Smile (2010-11-15 09:33) [6]

> Так что хотелось бы облегчить перенос "псевдоБД" в настоящую
> СУБД.

Почему бы сразу не начать работу с настоящей СУБД?

← →
sniknik © (2010-11-15 09:49) [7]

> Да ладно. Так не бывает.
> Пишется либо флаг (не в само поле) либо в поле пишется "спец значение" , говорящее что там нулл.
говоришь не бывает, а сам повторил по смыслу, другими словами буквально тоже самое... ???

неопределенный указатель это не значение, как и признак, не надо путать. значение поля, это то на что указатель указывает.
например это строка, так зачем под значение выделять память и т.д. вообще сохранять, если значения нет - NULL?

← →
Медвежонок Пятачок © (2010-11-15 10:06) [8]

это мы про какое выделение памяти?
сервера дисковую память распределяют не для полей и даже не для записей.
сервера выделяют дисковое пространство более крупными страницами.

и если после этого в поле "ничего не записать", то там все равно будет комбинация нулей и единиц.

← →
sniknik © (2010-11-15 10:42) [9]

> это мы про какое выделение памяти?
в дельфи менеджер тоже заранее выделяет, что не мешает после программисту выделять в "выделенном".

p.s. ты куда то не туда полез. хочешь запутать простую вещь? зачем?
давай тогда на уровень секторов диска, на то что н самом деле память это не "линейка", которая абстракция , и т.д.

← →
12 © (2010-11-15 10:54) [10]

чего там реально пишется - не важно совершенно.

> хотелось бы облегчить перенос "псевдоБД" в настоящую СУБД.

предлагаю писать "NULLNULL"
по аналогии с экранирующей "

← →
clickmaker © (2010-11-15 11:14) [11]

а какая связь между "что реально записывается в ячейку памяти в БД если значение поля NULL" и "хотелось бы облегчить перенос "псевдоБД" в настоящую СУБД"?
перенос-то не на физическом же уровне планируется?
главное договориться с утилитой импорта или кто-там будет переносить о формате данных, тем более что операция разовая

← →
Медвежонок Пятачок © (2010-11-15 11:25) [12]

ну например автор реализует у себя поле целочисленного типа.

Родилась новая запись. На диске или в памяти уже выделилось 4 байта под значение.
Если даже в них ничего не писать, то в поле все равно будет такая комбинация нулей и единиц, которую можно интерпретировать как валидное целочисленное значение.

Ну и как вы (без флага сбоку) отличите ситуацию, когда в поле лежит нулл?
Если все что там может лежать в принципе - стопудово правильный интегер.

← →
Вариант (2010-11-15 11:53) [13]

> Медвежонок Пятачок © (15.11.10 11:25) [12]

> Ну и как вы (без флага сбоку) отличите ситуацию, когда в
> поле лежит нулл?

Два варианта сразу (ну или полтора) -
все поля имеют текстовый вид, тип полей просто указывает как интерпретировать значение каждого поля. NULL можно записать явно, можно оставить значение пустым (ибо в простой разработке иметь разницу между empty и NULL необязательно).

PS:
А вообще почему не использовать готовое?
Для которого уже есть компоненты, или "легкие" базы данных, для чего уже есть средства преобразования и переноса в БД. Навскидку - файл с разделителями, TClientDataSet и XML, или Exel или акцесс + ADO. Комбинаций и вариантов может быть много. Причем при правильном выборе на потом возможно и программу не прийдется переделывать или ограничиться небольшими относительно переделками. И то возможно не в программе, а в базе.

PS:
Плюс для всего этого есть какие-никакие инструменты под рукой i, что бы разработать таблицы, указать типы данных. Создать диагррамму связей.

все поля имеют текстовый вид, тип полей просто указывает как интерпретировать значение каждого поля. NULL можно записать явно, можно оставить значение пустым (ибо в простой разработке иметь разницу между empty и NULL необязательно).

И сразу (если не любим оракл) напарываемся на холивар является ли пустая строка нулом.

← →
Вариант (2010-11-15 12:25) [15]

> Медвежонок Пятачок © (15.11.10 12:19) [14]

это во второй половине варианта:-) И то - если не оговорить заранее. А в файловом, временном хранилище на мой взгляд это неважно. Да и я бы не стал разрабатывать что-то, где надо ломать голову NULL или не NULLи какой он - я бы взял акцесс(кто любит другое - пусть будет другое), сделал бы в нем, а потом если надо легко бы перенес в другую СУБД.

← →
_Юрий (2010-11-15 19:20) [16]

Вопрос "как физически хранить NULL" напрямую зависит от физической реализации хранилища.
Если речь идет например об XML, то для этого вполне достаточен просто факт отсутствия атрибута или узла. Если это байтовый поток, то возможные варианты уже другие. А абстрактно тут рассуждать не о чем

> sniknik © (15.11.10 08:06) [1]
>
> есть очень четкое правило, при NULL в ячейку памяти БД не
> записывается ничего

Вот это "ничего" меня и интересовало.

> Облегчать перенос нужно с помощью общих интерфейсов доступа
> к данным

Это не моя задача. Да и перенос пока что только "возможно" "предполагается".

> Anatoly Podgoretsky © (15.11.10 09:07) [3]
>
> > Германн (15.11.2010 01:54:00) [0]
>
> Не твое дело, а записан там NULL
>

Пока как раз моё.

> Медвежонок Пятачок © (15.11.10 09:32) [5]
>
> в ячейку памяти БД не записывается ничего... значения нет
>
> Да ладно. Так не бывает.
> Пишется либо флаг (не в само поле) либо в поле пишется "спец
> значение" , говорящее что там нулл.
>

Флаг мне не нужен, а "спецзначение" я и выбрал для своей задачи.

> Smile (15.11.10 09:33) [6]
>
> > Так что хотелось бы облегчить перенос "псевдоБД" в настоящую
> > СУБД.
>
> Почему бы сразу не начать работу с настоящей СУБД?

Нет смысла использовать настоящую СУБД при однопользовательской работе с наборами данных, один из которых не превышает 2 тыс. записей, а остальные 254. Да и ещё нужно учесть, что запросы к этой псевдоБД крайне редки.
Тем более если речь идет о бесплатной программе. Зачем мне глюки постороннего дяди? Мне и своих хватит. :)

Резюме:
Не надо считать себя/казаться умнее, чем есть на самом деле.
Это я про себя.

Реальное значение NULL в СУБД Найти похожие ветки