Клубове Дир.бг
powered by diri.bg
търси в Клубове diri.bg Разширено търсене

Вход
Име
Парола

Клубове
Dir.bg
Взаимопомощ
Горещи теми
Компютри и Интернет
Контакти
Култура и изкуство
Мнения
Наука
Политика, Свят
Спорт
Техника
Градове
Религия и мистика
Фен клубове
Хоби, Развлечения
Общества
Я, архивите са живи
Клубове Дирене Регистрация Кой е тук Въпроси Списък Купувам / Продавам 16:38 17.05.24 
Клубове/ Компютри и Интернет / Бази данни Пълен преглед*
Информация за клуба
Тема Re: Професионален ? спор :) [re: Dakota]
Автор salle (Един такъв)
Публикувано10.10.02 12:44  



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

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

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

Съвсем общо правило (не конкретно за 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 - профилирайте си професионализизацията

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

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



Цялата тема
ТемаАвторПубликувано
* Професионален спор за NULL и Foreign Key (mySQL) Dakota   09.10.02 16:39
. * Re: Професионален спор за NULL и Foreign Key (mySQL) voyager   09.10.02 17:29
. * Re: Професионален спор за NULL и Foreign Key (mySQL) NDeu   09.10.02 19:23
. * Re: Професионален спор за NULL и Foreign Key (mySQL) RepeatableRead   09.10.02 19:46
. * Re: Професионален ? спор :) salle   10.10.02 12:44
. * Re: Професионален ? спор :) Dakota   10.10.02 13:51
. * Re: Професионален ? спор :) phpGuru   10.10.02 18:53
. * offtopic Xypodilec   10.10.02 14:52
. * Re: #define bira salle   11.10.02 13:05
Клуб :  


Clubs.dir.bg е форум за дискусии. Dir.bg не носи отговорност за съдържанието и достоверността на публикуваните в дискусиите материали.

Никаква част от съдържанието на тази страница не може да бъде репродуцирана, записвана или предавана под каквато и да е форма или по какъвто и да е повод без писменото съгласие на Dir.bg
За Забележки, коментари и предложения ползвайте формата за Обратна връзка | Мобилна версия | Потребителско споразумение
© 2006-2024 Dir.bg Всички права запазени.