Пролетно чистење на database проектот

[goce-smilevski]

Рекофме дека секој следен проект ќе се додава во постоечкиот LearnByPractice.sln, за да не завршиме на крајот со по еден solution по студент.

На Vid_Organizacija му фали UNIQUE KEY по името.

Во Oblast исто така треба ID IDENTITY(1, 1).

Во Tehnologija треба ID IDENTITY(1, 1). FK-то кон Oblast нека нема каскадно ништо (UPDATE на клучот нема да прајме, а за бришење не би било паметно со бришење на областа да се избришат и сите технологии). UK_Tehnologija_Oblast_ID значи дека ќе можиме да имаме само една технологија по област, шо реално не е случај (на пример, за Софтверско инженерство има еден куп технологии). Овај UNIQUE KEY не ни треба, ама добро би дошол секундарен индекс по полето Oblast_ID за да можи да се филтрира по области.

Во Predmet стандардно треба ID IDENTITY(1, 1).

Во Organizacija ID IDENTITY(1, 1), а и каскадните операции не ни требат на Vid_Organizacija_ID од истите причини наведени погоре.

Во Korisnik е најинтересно :)
Lozinka нека биди varbinary(255) зато шо ќе чуваме хаширана лозинка заедно со hash salt која ќе се користи за хаширање.
Studiska_Programa_ID не мора секогаш да постои, ако земиме дека корисници на системот можи да се и менторите и студентите и професорите ... значи нека е NULL-абилна.
Email малце пошироко, теоретски 255 карактери се поддржани.
ID IDENTITY(1, 1)
Во CK_Korisnik_Pol има едно непотребно празно место пред Ж-то.
Не ни требат ни каскаден UPDATE / DELETE на FK_Korisnik_Studiska_Programa.
Тука фалат тие трите bit полиња кои ќе кажат дали корисникот е администратор, дали е студент кој бара менторство или е ментор. Теоретски еден корисник можи да ги има уклучени сите 3 флега, па нека бидат посебни полиња.Согласно со логиката дека за студентите треба Studiska_Programa_ID, тука ќе треба еден CHECK CONSTRAINT кој ќе обезбеди дека ако флегот за студент е поставен на 1, тогаш и Studentska_Programa_ID е NOT NULL, а NULL во сите други случаи.

Во Ocenka исто така нејќиме каскадно ништо (можи за FK_Ocenka_Korisnik и би можело да остани, ама за предметите во никој случај). Нема да е лошо и еден CHECK CONSTRAINT кој ќе обезбеди валидни вредности за оценката (6 - 10 ?).

Во Prijava ID IDENTITY(1, 1) и засега евентуално уште едно поле со датум на пријавување. За каскадите мислам се разбрафме, нејќиме со бришење на организација да ни заминат сите пријави, туку сакаме да спречиме бришење на организација која има пријави. Не ќе е лошо да има секундарен индекс по Organizacija_ID за да можи фирмата која дава менторство побрзо да ги најди пријавите.

Во Prijava_Tehnologija исто така каскадите не ни требат, ама добро ќе ни дојди секундарен индекс по Tehnologija_ID за да можи побрзо да се пребара кои пријави се за одредена технологија.

Во Prijava_Korisnik каскадите не ни требат, ама ако веќе Prijava_ID е прво поле во PK, тогаш добро ќе ни дојди секундарен индекс по (Korisnik_ID, Prijava_ID) за да можи секој кориснико да си ги најди побрзо пријавите во кои фигурира.

Во рамки на Post-Deployment Scripts ќе ни треба една скрипта за Vid_Organizacija и една за Studiska_Programa со фиксни ID-ефци (овие табели немат IDENTITY(1, 1) зато шо се горе-долу фиксни и не се сменват толку често, а и да се сменат, то треба да е строго контролирано). Наредбата MERGE е корисна за пишење и тестирање на вакви скрипти, за да се осигуриме дека непостоечките записи ќе се додат а постоечките ќе се update-уват.

За тестирање на Publish на базата се користи publish profile во кој се наведуваат параметри за конекцијата со серверот и опции како да се постапи во одредени ситуации (нас рекофме дека засаега ќе ни треба опцијата Always re-create the database за да почнуваме се когаш од чиста ситуација).

За табелите Oblast, Tehnologija и Predmet ќе имаме исти такви Post-deployment скрипти, ама во посебен database проект TestDatabase, кој ќе го референцира Database проектот со табелите. Идејата е да имаме некакви почетни тест податоци (подоцна ќе додајме и за останатите табели како Korisnici), ама тие да бидат надвор од официјалната структура на базата. Нормално, и овај проект треба да е дел од LearnByPрactice.sln.

[Kukunoska]

Измените во базата во однос на IDENTITY својство, FK, UK, IX, CK, додавање на нов атрибут, промена на тип на вредност за некои атрибути, се завршени.

Останува да ги направам скриптите.

[goce-smilevski]

Ѓаолот лежи во деталите :)

Korisnik:
Lozinka треба да е 255, не max
Email исто
Administrator, Student и Mentor треба да се NOT NULL
Сите constraint-и имат Korinik во името, наместо Korisnik (поради последните гимнастики со табелите).
CK_Korinik_Studiska_Programa_ID - фториот услоф треба да важи кога Student = 0. Вака како шо е сега мислам дека ќе дозволи ситуација кога Student = 1 и Studiska_Programa_ID IS NULL. CHECK constraint треба да ги покрива двата услови експлицитно, двата случаи взаемно се исклучуваат ( или е студент со студиска програма, или не е студент и нема студиска програма).
Фали FK кон Organizacija.

Ocenka:
Зошто со LIKE се испитва вредност на int колона ? LIKE обично се користи за стринг податоци (varchar, nvarchar и сл.).

[Kukunoska]

Деталите поправени, ѓаволот избркан :)

[goce-smilevski]

Гледам, гледам, одлично ... зборот ми беше дека финесите се она шо ја прај разликата меѓу лоша и добра имплементација.Ајде сега скриптите.

[Kukunoska]

ОК :)

[goce-smilevski]

Еве еден корисен пример, кој главно ќе е применлиф за hard-code--ираните табели, ама можи да се употреби и за lookup табелите со IDENTITY(1, 1) како на пример Oblast и Predmet, ако се бара по име.. За Tehnologija ќе е малце посложено, тука ќе треба со JOIN да се најди Oblast_ID, па на пример да се бара по име на областа. Можи и со користење на table variables или sub-query и обични T-SQL променливи да се избегни пофторвање на описите на областите шо имат по појќе технологии .. ама ајде прво за наједноставните табели.

[goce-smilevski]

А шо велиш за нешто вакво:

MERGE INTO [dbo].[Vid_Organizacija] AS [target]
USING
    (VALUES
        (1, N'Образовна институција'),
        (2, N'Приватна фирма')
    ) AS [source] (id, ime)
ON [target].[ID] = [source].[id]
WHEN MATCHED THEN
    UPDATE SET Ime = [source].[ime]
WHEN NOT MATCHED BY TARGET THEN
    INSERT ([ID], [Ime]) VALUES ([source].[id], [source].[ime])
WHEN NOT MATCHED BY SOURCE THEN
    DELETE
;

Ова ќе функционира за хард-кодираните табели, за оние другите шифрарници ќе треба да се смисли нешто, на пример да се прај JOIN-от по име на пример за почеток, наместо по id. Ама во секој случај, MERGE скриптата е попаметна и позгодна за користење отколку ако има само INSERT или да има испитвање со INSERT / UPDATE / DELETE и со IF.