|
|
| Тема |
 Професионален спор за NULL и Foreign Key (mySQL) |
|
| Автор |
Dakota (гол на деня) |
|
| Публикувано | 09.10.02 16:39 |
|
|
|
С един колега спорихме за това, трябва ли 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.
"
"Да живееш - значи да се променяш." - Анатол Франс
| |
| |
| 
|
|
