Codd“s 12 rules (1985)

● Правило 0: Основное правило (Foundation Rule):

Система, которая рекламируется или позиционируется как реляционная система управления базами данных, должна быть способна управлять базами данных, используя исключительно свои реляционные возможности

● Правило 1: Информационное правило (The Information Rule)
Вся информация в реляционной базе данных на логическом уровне должна быть явно представлена единственным способом: значениями в таблицах.

● Правило 2: Гарантированный доступ к данным (Guaranteed Access Rule):
В реляционной базе данных каждое отдельное (атомарное) значение данных должно быть логически доступно с помощью комбинации имени таблицы, значения первичного ключа и имени столбца.

● Правило 3: Систематическая поддержка отсутствующих значений (Systematic Treatment of Null Values):

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

● Правило 4: Доступ к словарю данных в терминах реляционной модели (ActiveOn-Line Catalog Based on the Relational Model):

Словарь данных должен сохраняться в форме реляционных таблиц, и СУБД должнаподдерживать доступ к нему при помощи стандартных языковых средств, тех же самых, которые используются для работы с реляционными таблицами, содержащими пользовательские данные.

● Правило 5: Полнота подмножества языка (Comprehensive Data Sublanguage Rule):

Система управления реляционными базами данных должна поддерживать хотя бы один реляционный язык, который
(а) имеет линейный синтаксис,
(б) может использоваться как интерактивно, так и в прикладных программах,
(в) поддерживает операции определения данных, определения представлений, манипулирования данными (интерактивные и программные), ограничители целостности, управления доступом и операции управления транзакциями (begin, commit и rollback).

● Правило 6: Возможность изменения представлений (View Updating Rule):

Каждое представление должно поддерживать все операции манипулирования данными, которые поддерживают реляционные таблицы: операции выборки, вставки, изменения и удаления данных.

● Правило 7: Наличие высокоуровневых операций управления данными (HighLevel Insert, Update, and Delete):

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

● Правило 8: Физическая независимость данных (Physical Data Independence):

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

● Правило 9: Логическая независимость данных (Logical Data Independence):

Представление данных в приложении не должно зависеть от структуры реляционных таблиц. Если в процессе нормализации одна реляционная таблица разделяется на две, представление должно обеспечить объединение этих данных, чтобы изменение структуры реляционных таблиц не сказывалось на работе приложений.

● Правило 10: Независимость контроля целостности (Integrity Independence):

Вся информация, необходимая для поддержания целостности, должна находиться в словаре данных. Язык для работы с данными должен выполнять проверку входных данных и автоматически поддерживать целостность данных.

● Правило 11: Независимость от расположения (Distribution Independence):

База данных может быть распределённой, может находиться на нескольких компьютерах, и это не должно оказывать влияния на приложения. Перенос базы данных на другой компьютер не должен оказывать влияния на приложения.

● Правило 12: Согласование языковых уровней (The Nonsubversion Rule):

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

Лучшее время чтобы начать новую таску: спустя два часа. За это время, у тим лида она полностью поменяется - > переписывать не надо.

Что такое IaaS, PaaS, SaaS?

IaaS — Infrastructure as a Service — инфраструктура как услуга, например, виртуальные серверы и виртуальная сеть; клиент может устанавливать любое программное обеспечение и приложения;

PaaS — Platform as a Service — платформа как услуга, например, веб-сервер или база данных; клиент управляет приложениями, операционной системой управляет провайдер;

SaaS — Software as a Service — программное обеспечение как услуга, например, электронная почта или иное офисное приложение; клиент пользуется приложением, базовыми настройками приложения управляет провайдер.

Источник

Требования подобны воде. Опираться на них легче, если они заморожены.

Стив Макконнелл

PostgreSQL проверка на NULL.

Параметр transform_null_equals

Пример: "expr=NULL" as "expr IS NULL"

Когда этот параметр включён, проверки вида выражение = NULL (или NULL = выражение) воспринимаются как выражение IS NULL, то есть они истинны, если выражение даёт значение NULL, и ложны в противном случае. Согласно спецификации SQL, сравнение выражение = NULL должно всегда возвращать NULL (неизвестное значение). Поэтому по умолчанию этот параметр выключен (равен off).

Однако формы фильтров в Microsoft Access генерируют запросы, в которых проверка на значение NULL записывается как выражение = NULL, так что если вы используете этот интерфейс для обращения к базе данных, имеет смысл включить данный параметр. Так как проверки вида выражение = NULL всегда возвращают значение NULL (следуя правилам стандарта SQL), они не очень полезны и не должны встречаться в обычных приложениях, так что на практике от включения этого параметра не будет большого вреда. Однако начинающие пользователи часто путаются в семантике выражений со значениями NULL, поэтому по умолчанию этот параметр выключен.

Заметьте, что этот параметр влияет только на точную форму сравнения = NULL, но не на другие операторы сравнения или выражения, результат которых может быть равнозначен сравнению с применением оператора равенства (например, конструкцию IN). Поэтому данный параметр не может быть универсальной защитой от плохих приёмов программирования.

Источник

Java

Контракт между equals и hashcode.

Java

Java Primitive data type on Stack or Heap?

class  Test
{
    int y=10; // defined as part of the class

    public void function1(){
        int x = 5; // defined locally
    }

    public static void main(String[] args) 
    {
        Test obj = new Test();
    }
}

Ответ 1

Когда вызывается метод, определенные данные помещаются в стек. Когда метод завершается, данные удаляются из стека. В другие моменты выполнения программы данные добавляются в стек или удаляются из него.

Следовательно, если у вас есть переменная, которая предназначена для того, чтобы пережить выполнение метода, который ее создал, она должна находиться в куче. Это применимо как к любым создаваемым вами объектам, так и к любым примитивам, которые хранятся в этих объектах.

Однако, если переменная должна выйти из области видимости вскоре после ее создания - скажем, в конце метода, в котором она была создана, или даже раньше, тогда эта переменная будет создана в стеке. Этому критерию соответствуют локальные переменные и аргументы метода; если они примитивы, фактическое значение будет в стеке, а если они являются объектами, ссылка на объект (но не сам объект) будет в стеке.

В вашем конкретном примере x становится непригодным для использования, как только функция function1 завершает работу. Поэтому разумно создать его в стеке. В конце function1 данные удаляются из стека, включая x. С другой стороны, ожидается, что переменная y будет существовать до тех пор, пока существует содержащий объект; если бы он был создан в стеке, он перестал бы существовать, как только конструктор объекта, который его создал, завершит работу. Следовательно, y должен быть создан в куче.


Ответ 2

В стеке хранятся только локальные примитивные переменные и ссылки на объект (т.е. переменную, объявленную в методе). Остальные хранятся в куче

Waiting for PostgreSQL 11 – Fast ALTER TABLE ADD COLUMN with a non-NULL default

Fast ALTER TABLE ADD COLUMN with a non-NULL default


Currently adding a column to a table with a non-NULL default results in
a rewrite of the table. For large tables this can be both expensive and
disruptive. This patch removes the need for the rewrite as long as the
default value is not volatile. The default expression is evaluated at
the time of the ALTER TABLE and the result stored in a new column
(attmissingval) in pg_attribute, and a new column (atthasmissing) is set
to true. Any existing row when fetched will be supplied with the
attmissingval. New rows will have the supplied value or the default and
so will never need the attmissingval.

Any time the table is rewritten all the atthasmissing and attmissingval
settings for the attributes are cleared, as they are no longer needed.

The most visible code change from this is in heap_attisnull, which
acquires a third TupleDesc argument, allowing it to detect a missing
value if there is one. In many cases where it is known that there will
not be any (e.g. catalog relations) NULL can be passed for this
argument.

Andrew Dunstan, heavily modified from an original patch from Serge
Rielau.
Reviewed by Tom Lane, Andres Freund, Tomas Vondra and David Rowley.

Full: https://www.depesz.com/2018/04/04/waiting-for-postgresql-11-fast-alter-table-add-column-with-a-non-null-default/