Difference between revisions of "RU/kb/00000354"
(section begin=title) |
|||
(5 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | <section begin=title /><noinclude>{{DISPLAYTITLE:База Знаний: | + | <section begin=title /><noinclude>{{DISPLAYTITLE:База Знаний: {{OOoB|1}}. </noinclude>Проверка на NULL-значения в форме<noinclude>}}</noinclude><section end=title /> |
{{BreadCrumbL10n|RU/kb/module/base/forms}} | {{BreadCrumbL10n|RU/kb/module/base/forms}} | ||
__NOTOC__ | __NOTOC__ | ||
+ | {{RUfromforum|17451}} | ||
В реляционных базах данных (RDBMS) поддерживается контроль целостности данных на уровне описания структуры таблиц (DML). В том числе, можно указать, какие поля не должны содержать неопределённые (NULL) значения<ref>Не следует путать неопределённое значение (NULL) и такие как пустая строка (""), ЛОЖЬ (FALSE) или ноль (0)</ref>. Проверка этих условий осуществляется средствами самой RDBMS и не зависит от способа добавления/изменения данных (через форму, командную строку или файл сценария). | В реляционных базах данных (RDBMS) поддерживается контроль целостности данных на уровне описания структуры таблиц (DML). В том числе, можно указать, какие поля не должны содержать неопределённые (NULL) значения<ref>Не следует путать неопределённое значение (NULL) и такие как пустая строка (""), ЛОЖЬ (FALSE) или ноль (0)</ref>. Проверка этих условий осуществляется средствами самой RDBMS и не зависит от способа добавления/изменения данных (через форму, командную строку или файл сценария). | ||
Line 51: | Line 52: | ||
− | {{ | + | {{SignYear|Denis0.ru|Д. В. Черносов|2010 }} |
{{RUkbBaseBottom}} | {{RUkbBaseBottom}} |
Latest revision as of 18:24, 24 March 2012
Материал для этой статьи сформулирован на основе обсуждения
в community.i-rs.ru.
В реляционных базах данных (RDBMS) поддерживается контроль целостности данных на уровне описания структуры таблиц (DML). В том числе, можно указать, какие поля не должны содержать неопределённые (NULL) значения[1]. Проверка этих условий осуществляется средствами самой RDBMS и не зависит от способа добавления/изменения данных (через форму, командную строку или файл сценария).
Однако, в ряде случаев, лучше проводить дополнительную проверку на стороне клиента, до отправки запроса к SQL-серверу.[2] [3]
В формах OpenOffice.org у многих элементов управления (текстовые поля, поля форматированного ввода и других) в Свойствах элемента на закладке Данные есть пара свойств:
- "пустая строка - NULL" да/нет,
- "требуется ввод данных" да/нет.
Если первое свойство выставлено в значение "да", то активируется второе.
Между DML описанием таблицы и настройками элементов формы OpenOffice.org существует следующая связь[4]:
DML,
NOT NULL |
Форма,
"требуется ввод данных" |
Результат попытки сохранить NULL значение в БД |
---|---|---|
не указано | любое значение | Значение сохраняется.
Настройки формы игнорируются. |
указано | да | Значение не сохраняется. Выводится локализованное предупреждение OpenOffice.org.
Т.е. срабатывает ограничение на стороне клиента. |
указано | нет | Значение не сохраняется. Выводится предупреждение SQL-движка.
Т.е. срабатывает ограничение на стороне сервера. |
- ↑ Не следует путать неопределённое значение (NULL) и такие как пустая строка (""), ЛОЖЬ (FALSE) или ноль (0)
- ↑ Хотя по умолчанию, данные и формы для доступа к ним хранятся в одном файле odb, всё равно имеет место клиент-серверная архитектура. Запросы, Формы и Отчёты - это клиентская сторона (интерфейс), которая посредством SQL-запросов общается с HSQLDB-сервером. А он уже осуществляет все низкоуровневые операции чтения/записи в двоичные файлы данных.
- ↑ Проверка на стороне клиента добавляет некоторые возможности, но не заменяет корректное DML-описание таблиц!
- ↑ Проверено на встроенной HSQLDB