С един колега спорихме за това, трябва ли Foreign Keys в mysql (знам, че в mysql няма такова животно, става дума за полето, по което се join-ва) да бъдат оставяни NULL или да се слагат на NOT NULL? Моята позиция беше за NOT NULL и default '0'...като аргументите ми бяха предимно взети от mysql reference глава 5.4.2, а именно:

"Declare columns to be NOT NULL if possible. It makes everything faster and you save one bit per column. Note that if you really need NULL in your application you should definitely use it. Just avoid having it on all columns by default."

Ако някой може да ми даде подробности за това, защо е faster и кога наистина се налага едно поле да е NULL? Ако от едната страна то е NOT NULL като Primary Key, защо от другата страна да е NULL?

От друга страна, наистина има join заявки, при които искам като резултат да ми бъде върнат NULL, а не, че 100>0 примерно...т.е. в контекста на join, NOT NULL може да бъде и опасно.

В тази връзка искам да зачекна и въпроса за това, трябва ли ВСИЧКИ primery keys на базата да са от един тип? Примерно ако в едната таблица ми трябва BIGINT, каква е причината, да сложа BIGINT на таблица, в която ще имам най-много 3 стойности?! Позовавам се отново на гореспоменатата глава...и по-специално:

"One of the most basic optimization is to get your data (and indexes) to take as little space on the disk (and in memory) as possible...

...Use the most efficient (smallest) types possible. MySQL has many specialized types that save disk space and memory.
Use the smaller integer types if possible to get smaller tables. For example, MEDIUMINT is often better than INT.
"

"Да живееш - значи да се променяш." - Анатол Франс

Принципно защо като няма НУЛЛ е по-бързо в подробности може да каже някой който познава много добре МуСКЛ. Мисля, че има такъв в клуба . Колкото това дали е така, опита показва, че е истина. Честно казано, никога не използвам полета с нулл за каквото и да е. Винаги се намира начин да представиш НУЛЛ с някаква стойност /*не задължително нула*/.
Колкото до еднаквите типове на полетата праймъри кейс, вероятно причината е в аритмечиното изравняване на типовете, което би трябвало да се прави, както се прави в процедурните езици. Мда. Ама тва са една кофа мнения само, нищо повече

Съдържаниет е скрито
Влезте за да го видите

1.Без да конкретизирам за MySQL (не го познавам ) по принцип няма смисъл Foreign Key да е Null, защото той трябва да сочи към съществуващ запис в детайла.
2. За скоростта - хората са го казали ясно. Бих добавил само, че това е вярно не само за MySQL.
3.Без да конкретизирам за MySQL (не го познавам ) по принцип няма ограничение (почти) какъв тип ти е Primary Key (ако щеш и VarChar), но разбира се трябва да има идентичност със съответния Foreign Key

Ако логиката на данните го изисква може Foreign-key да се сложи NULL, но тогава ще се налага да се правят външни join-ове. Зависи какво се изисква и какво трябва да се постигне. Иначе NULL понякога е много удобно. Но все пак трябва да се внимва.

С един колега спорихме за това, трябва ли ...

Непрофесионално - няма такова мещо като трябва изобщо.

Професионално би било да попиташ:
Може ли? Ако може какъв е смисъла? Кога би могло това да върши работа? Какви проблеми може да създаде? А ето в този конкретен случай какви са плюсовете и минусите?

Съвсем общо правило (не конкретно за MySQL) - представи си, че ти си сървъра. Ако знаеш че може да бъде и NULL - трябва да правиш една проверка повече. А и трябва някъде да пазиш тази информация.

Много внимателно обаче обсъдете с твоя колега втората част от текста който си цитирал:

"Note that if you really need NULL in your application you should definitely use it. Just avoid having it on all columns by default."

Да не истанеш с впечатлението, че е по-добре да не използваш NULL.

> В тази връзка искам да зачекна и въпроса за това, трябва ли ВСИЧКИ primery keys на базата да са от един тип?

Още по-непрофесионално. Пак думичката трябва. Освен това забравяш, че PK (както и всеки Index) няма тип. Тип имат колоните които са индексирани а това е съвсем друго нещо.

Какъв е типът на следния PK:

g_id INT UNISGNED,
u_name CHAR(16),
ts TIMESTAMP,

PRIMARY KEY(g_id, u_name, ts) ?


Позоваваш се на цитирания текст изцяло извън контекста.

В него се говори за съвсем очевидното правило, че трябва да минимизираш обема. Не за уеднаквяване.

Има друго правило, че когато правиш Join препоръчително е колоните които участват в Join условието да са от еднакъв тип. В MySQL не е задължително, но работи по-бързо. Логиката е ясна - когато имаш да сравниш 100 000 стойности ако типа е различен имаш 100 000 преобразувания на тип.

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

А това е едно универсално явление - почти винаги и навсякъде оптимизираш

Обем срещу Скорост.
Или обемисто и бързо или компактно но бавно.

Тъй че Dakota - профилирайте си професионализизацията

така де ... работете заедно по един проект и спорете, че ето те тука те ако отрежем един бит ще помогне....

оставете думичката трябва за изрази като
Трябва да изпием по бира

Съдържаниет е скрито
Влезте за да го видите

Изразът трябва не го измислих аз, просто цялата фраза която чух беше:

"Прието е всички primary да са от един тип"

И на моя въпрос "Защо?", беше отгорено с: "Повярвай ми, така е...така е прави"

И именно затова питам, защо трябва?!

Разбира се, това, по което се join-ва е от един тип, въпросът ми беше, има ли наистина конвенция auto_increment полетата (те поне са по едно на таблица ) да бъдат от един тип във всички таблици? И ако да - защо?!

Относно NULL, въпросът ми е принципен...т.е. наистина ли е въпрос на личен избор в конкретния случай, или е едното е по-добро от другото...или с други думи: "Има ли поне една наистина добра причина да слагам FK NULL, освен за лична информация?"

И при бирата няма думичката трябва, там си е по подразбиране...

"Да живееш - значи да се променяш." - Анатол Франс

ракията за нищо я нямаш май

Съдържаниет е скрито
Влезте за да го видите

тъп пример и абсолютно неразбран може би ;-))

CREATE TABLE colors (
id serial NOT NULL PRIMARY KEY,
name varchar(64) NOT NULL
);

INSERT INTO color VALUES ('червен')
-- и други цветове

и сега един вариант

CREATE TABLE cars (
id serial NOT NULL primary key,
name varchar(128) NOT NULL,
color int4 NULL REFERENCES colors
);

и друг

CREATE TABLE car (
id serial NOT NULL primary key,
name varchar(128) NOT NULL,
color int4 NOT NULL REFERENCES color
);

проблема е винаги ли знаеш цвета на колата,

първият вариант допуска такова незнание и при евентуален JOIN то ще бъде пропуснат (тук съвсем я окалпах, ама ме цепи глава и немога да се връщам), (ако искаш да фанеш и неопределените цветове ползваш OUTER JOIN)

вторият вариант ако искаш да има цвят неопределен си вмъкваш в първата таблица ред
INSERT INTO color VALUES ('неопределен')
и тогава обаче при JOIN винаги ще се проверява и в таблицата color и приложението трябва да прави то проверка, дали това е неопределен

аз харесвам първият вариант когато може да не се знае цвета и вторият вариант когато цвета е задължителен
________________________

ако е адски неясно друг път ще пояснявам кво съм искал да кажа

Ракията ми седи във фризера - т.е. винаги има бутилка там. Като я извадиш при -18 е супер

"Бира" е размит термин - означава "каквото пиеш"

Май наистина напоследък по-често пия бира обаче.

Хайде наздраве

Съдържаниет е скрито
Влезте за да го видите