plik


ÿþRozdziaB 4 Konwencje Niezwykle istotnym czynnikiem, uBatwiajcym tworzenie aplikacji klient-serwer, jest konsekwentne stosowanie standardowych konwencji nazewnictwa i metod zapisu programu. Problematyka ta wydaje si na tyle istotna, |e jej omówienie poprzedzi wBa[ciwe informacje na temat budowania aplikacji. Niniejszy rozdziaB zawiera szereg uwag na temat nazewnictwa elementów aplikacji klient-serwer, napisanych w Delphi. Uwagi te odnosi si bd do elementów aplikacji klienta i serwera, które omawiane bd oddzielnie. Zawarto[ tego rozdziaBu nale|y traktowa wyBcznie jako zbiór sugestii. Czytelnicy powinni wybra takie metody nazewnictwa i zapisu programu, jakie im najbardziej odpowiadaj. Znacznie istotniejsze od wyboru konkretnej konwencji jest jej konsekwentne stosowanie. Elementy programu w jzyku Object Pascal Dyskusj na temat nazewnictwa rozpoczniemy od elementów programu w Delphi. Do elementów tych zaliczy mo|na komponenty, formularze, moduBy danych, moduBy kodu (units), zmienne, staBe, itd. Innymi sBowy, za elementy programu w Delphi uznajemy wszystkie te elementy, które nie s wprost zwizane z serwerem bazy danych. Do elementów zwizanych z serwerem bazy danych zaliczamy m.in. tabele, indeksy, widoki, wyzwalacze, procedury osadzone, reguBy, warto[ci domy[lne, itd. UWAGA: Z uwagi na ró|norodno[ wykorzystywanych obecnie [rodowisk sieciowych, nale|y w miar mo|liwo[ci unika stosowania dBugich nazw plików, dozwolonych w Windows 95/NT. Wprawdzie Delphi doskonale radzi sobie z nazwami dBu|szymi ni| 8 znaków, jednak czsto zdarza si, |e aplikacja musi wspóBpracowa z sieciowym systemem operacyjnym lub dziaBa na komputerze, na którym nazwy takie nie s dozwolone. Jest to szczególnie prawdopodobne w przypadku aplikacji typu klient-serwer, które czsto korzystaj z serwerów rezydujcych na innym komputerze. 88 Cz[ I Mo|na si spodziewa, |e w niedalekiej przyszBo[ci wikszo[ serwerów i sieci bdzie dopuszcza stosowanie dBugich nazw plików. Obecnie jednak wci| jeszcze wskazana jest pow[cigliwo[ w korzystaniu z tego udogodnienia. Katalogi Omówienie rozpoczniemy od katalogów, gdy| ich struktura bywa czsto równie wa|na, jak sama zawarto[. Wszystkie dane, niezale|nie od ich typu, dobrze jest przechowywa na dysku w jednym, wspólnym katalogu, o nazwie DATA (DANE). Umo|liwia to wykonanie kopii bezpieczeDstwa wszystkich danych poprzez proste skopiowanie zawarto[ci katalogu DATA i jego podkatalogów. W obrbie katalogu DATA utworzy mo|na podkatalogi, odpowiadajce poszczególnym aplikacjom - jeden podkatalog dla programu Word Perfect for Windows, drugi dla Delphi, trzeci dla Quattro Pro for Windows, itd. UBatwi to odszukanie pliku utworzonego przy u|yciu okre[lonej aplikacji. Taki sposób postpowania odbiega od modnego ostatnio systemu pracy  zorientowanej na przetwarzanie dokumentu, a nie uruchamianie aplikacji , jest jednak dobrze sprawdzony w praktyce. W ramach podkatalogu ka|dej aplikacji umie[ci mo|na podkatalogi odpowiadajce poszczególnym projektom. Na przykBad, projekt RentalMan ( zarzdzanie wynajmem ), opracowywany w cz[ci  Tutorial niniejszej ksi|ki, mógBby rezydowa w katalogu C:\DATA\DELPHI3\RENTMAN. W praktyce bardzo rzadko stosuje si rozszerzenia nazw katalogów. Katalogi powinny mie nazwy Batwe do rozpoznania i zapamitania - takie, które równie dobrze mogByby identyfikowa segregatory stojce na póBce. W istocie, katalogi  udaj przecie| segregatory z dokumentami. Z powy|szych zasad wynika, |e je[li projekt opracowywany jest przy pomocy kilku programów, to nale|y utworzy podkatalog projektu, o identycznej nazwie, w podkatalogu ka|dej z aplikacji. Oczywi[cie - jak ju| wspomniano - powy|sze reguBy nale|y traktowa wyBcznie jako sugesti autora, opart na jego wBasnych do[wiadczeniach. UWAGA: Windows 95 automatycznie zakBada katalog o nazwie Moje Dokumenty, analogiczny do wspomnianego katalogu DATA. W Windows 95 podkatalogi przyjto nazywa folderami. Foldery tworzy si m.in. w programie Eksplorator. Konwencje 89 Nazwy projektów Nazwy projektów powinny by rozpoznawalne i logiczne, a jednocze[nie zgodne z konwencj nazewnictwa plików  8+3 . Nie nale|y zmienia standardowego rozszerzenia, nadawanego przez Delphi plikom projektów. W rezultacie dBugo[ nazwy projektu zostaje ograniczona do zaledwie o[miu znaków. Nazwa taka powinna by identyczna z nazw katalogu, w którym przechowywany jest projekt. Dziki temu mo|liwe bdzie Batwe ustalenie, skd pochodzi plik, przeniesiony tymczasowo w inne miejsce albo skopiowany na dysk kolegi. Nazwy plików Plikom dobrze jest nadawa nazwy czytelne, logiczne i  rozszerzalne .  Rozszerzalno[ mo|na osign przeznaczajc jedn lub dwie ostatnie cyfry nazwy na numer kolejny wersji. Dziki takiej numeracji mo|liwe jest przechowywanie kilku wersji pliku, z zachowaniem jego gBównej nazwy. PrzykBadowo na dysku autora plik, zawierajcy niniejszy rozdziaB, nosi nazw CSD0400. Kolejne, zmodyfikowane nazwy pliku zapisywane s pod nazwami CSD0401, CSD0402, itd. Sposób ten umo|liwia szybkie rozpoznanie ostatniej wersji pliku, bez odczytywania daty i godziny jego utworzenia. Ponadto bardzo Batwo mo|na przenie[, skopiowa lub spakowa wszystkie wersje pliku, korzystajc z wieloznacznej nazwy plików (zawierajcej tzw. wildcards, np.  CSD04?? ). Opisany powy|ej sposób nazywania plików przyrówna mo|na do prymitywnego systemu zarzdzania tekstem zródBowym programów. Mimo swojej prostoty system dziaBa. Inn praktyczn zasad jest dodawanie na pocztku nazwy pliku przynajmniej jednej litery, identyfikujcej projekt, którego plik dotyczy. Pliki nale|ce do danego projektu wygldaj wówczas podobnie i Batwiej jest nimi zarzdza. Wszystkie pliki nale|ce na przykBad do  systemu zarzdzania wynajmem i konserwacj (Rental Maintanance Management System), budowanego w cz[ci  Tutorial niniejszej ksi|ki, nosz nazwy rozpoczynajce si liter R. Po literze, identyfikujcej projekt, mo|na wpisa od trzech do sze[ciu znaków opisujcych ogólne przeznaczenie pliku. Je|eli plik nie ma poza tym |adnego szczególnego przeznaczenia, to mo|na je scharakteryzowa przy pomocy wszystkich sze[ciu znaków, pozostajcych do dyspozycji przed numerem kolejnym wersji. Je[li mo|na wyró|ni jakie[ szczególne przeznaczenie pliku, to trzy litery nale|y po[wici na symbol ogólnego zastosowania pliku, a trzy kolejne na opis szczegóBowego przeznaczenia. W systemie zarzdzania wynajmem i konserwacj (Rental Maintenance Management) wystpuje na przykBad plik, który zawiera fragment programu odpowiedzialny za obsBug okna dialogowego do edycji tabeli CALLS (zgBoszenia telefoniczne). Plik ten nosi nazw RCALEDT0 - od  Rental maintenance management system , okno dialogowe Call Edit. 90 Cz[ I Nazwy moduBów Podobnie jak nazwy plików, tak i nazwy moduBów (units) mog by dowolnie dBugie, przy czym kompilator rozró|nia nazwy wyBcznie na podstawie pierwszych 63 znaków. Jak ju| wspomniano, nale|y unika nadawania nazw dBu|szych ni| o[mioznakowe. Na podstawie nazwy moduBu Delphi tworzy odpowiedni nazw dla pliku PAS, dlatego nadanie moduBowi nazwy dBu|szej ni| o[mioznakowa spowoduje utworzenie pliku o równie dBugiej nazwie. Nazwy komponentów Poniewa| nie wystpuje bezpo[rednia relacja midzy nazwami plików a nazwami komponentów, te ostatnie powinny by jak najbardziej opisowe - z zastrze|eniem, |e zbyt dBug nazw bdzie trudno wpisywa z klawiatury. Nazwy powinny by Batwe do wymówienia i dobrane logicznie. Nale|y tak|e zaleci stosowanie w nazwach komponentów zarówno du|ych, jak i maBych liter. W nazwach komponentów nie mo|na u|ywa spacji, dlatego najlepszym sposobem oddzielania sBów w nazwie jest rozpoczynanie ka|dego z nich wielk liter. Wreszcie, zaleca si rozpoczynanie wszystkich nazw typów w jzyku Pascal (w tym definicji komponentów, które formalnie s klasami) du| liter T. Konwencji tej u|ywaj powszechnie autorzy biblioteki Visual Component Library, dostarczanej w pakiecie Delphi. Dziki niej definicje typów bardzo Batwo mo|na wyró|ni w tek[cie programu. Na przykBad, komponent array table z rozdziaBu 3, uBatwiajcy dostp do tabel baz danych, nosi nazw TArrayTable. Litera T wskazuje, |e jest to klasa, zdefiniowana w jzyku Object Pascal. Opisowa cz[ identyfikatora - ArrayTable - charakteryzuje przeznaczenie komponentu. Nadajc nazwy komponentom dostarczanym standardowo w pakiecie Delphi, dobrze jest u|ywa dwu-, trzy- lub czteroliterowego symbolu, zapisywanego maBymi literami i umieszczanego przed wBa[ciw nazw komponentu. Nazwy komponentów Memo mog zatem rozpoczyna si od symbolu me; nazwy kontrolek typu Edit rozpoczynaByby si w tej samej konwencji od liter ed. PozostaBa cz[ nazwy ma w takim wypadku charakter opisowy, np. edIdKlienta, edCustomer Name lub meKomentarz. W tabeli 4.1 zebrano skrócone identyfikatory typów komponentów. Stanowi one oczywi[cie jedynie sugesti autora. Nale|y zwróci uwag, |e na li[cie wystpuj tak|e klasy Form (formularze) i Data Module (moduBy danych) - ich nazwy równie| powinny mie[ci si w przyjtej konwencji. Wszystkie komponenty, reprezentujce pola dialogowe, oznaczone s dwuliterowym skrótem, po którym nastpuje znak podkre[lenia (_). Tak skonstruowane nazwy powinny wyró|nia si w tek[cie programu. ReguB jest tak|e rozpoczynanie nazw wszystkich kontrolek, zwizanych z bazami danych, od litery d. Po niej nastpuje skrót wBa[ciwy dla odpowiedniej standardowej kontrolki, Konwencje 91 na przykBad kontrolce Edit odpowiada kontrolka DBEdit, powizana z baz danych. Kontrolki Edit oznacza si symbolem ed, natomiast DBEdit - ded. Tabela 4.1 Komponenty Delphi i zalecane skróty Component - Komponent Abbreviation - Skrót Animate an AutoObject ao BitBtn bb BatchMove bm Bevel be BDEProvider bp BDEResolver br Button bt ColorDialog co_ Calendar ca ComboBox cb DdeClientConv cc ClientDataSet cd. DecisionCube cde DecisionSource cds DecisionGraph cgp DecisionGrid cgr DecisionPivot cpi DecisionQuery cqu ColorGrid cg Chart ch DdeClientItem ci CheckBox ck Coolbar co ClientSocket cs ChartFX cx 92 Cz[ I Component - Komponent Abbreviation - Skrót Database db DriveComboBox dc DBComboBox dcb DBCtrlGrid dcg DBChart dch DBCheckBox dck DBEdit ded DBGrid dgr DBImage dim DirectoryListBox dl DBListBox dlb DBLookupComboBox dlcb DBLookupCombo dlco DBLookupListBox dllb DBlooupList dlli DataModule dm DBMemo dme DBNavigator dna DirectoryOutline do DataSetTableProducer dp DrawGrid dr DBRadioGroup drg DataSource ds DateTimePicker dt DBText dte Edit ed F1Book f1 FilterComboBox fc FindDialog fi_ FileListBox fl Konwencje 93 Component - Komponent Abbreviation - Skrót Form fm FontDialog fo_ Gauge ga GroupBox gb Graph gr GraphicsServer gs HeaderControl hc HTTPDispatcher hd Header he HotKey hk HTMLPageProducer hp HTMLQueryTableProducer hq HTMLDataSetTableProducer ht IBEventAlerter ie ImageList il Image im Label la ListBox lb ListView lv MaskEdit md Memo me MainMenu mm MediaPlayer mp MemoryDataSet ms Notebook nb OpenDialog od_ OleContainer ol OpenPictureDialod op_ Outline ou Panel pa 94 Cz[ I Component - Komponent Abbreviation - Skrót PaintBox pb PageControl pc ProgressBar pr PrintDialog pr_ PageProducer pp PrinterSetupDialog ps_ PopupMenu pu QRBand qba QRChildBand qcb QRChart qch QRCompositeReport qcr QRDBCalc qdc QRDBImage qdi QRDetailLink qdl QRDBText qdt QREditor qed QRExpr qex QRGroup qgr QRImage qim QRLabel qla QRMemo qme QueryTableProducer qp QRPreview qpr QuickReport qr QRRichText qrt QRSysData qsd QRSubDetail qsd QRShape qsh Query qu RadioButton rb Konwencje 95 Component - Komponent Abbreviation - Skrót RichEdit re ReplaceDialog re_ RadioGroup rg Report rp RemoteServer rs ScrollBar sa SaveDialog sa_ SpeedButton sb DdeServerConv sc SpinEdit sd Session se StringGrid sg DdeServerItem si Splitter sl StoredProc sp SavePictureDialog sp_ ServerSocket ss StatusBar st SpinButton su ScrollBox sx Table ta TrackBar tb TabControl tc Thread th Timer ti TabbedNotebook tn Toolbar to TabSet ts TreeView tv UpDown ud 96 Cz[ I Component - Komponent Abbreviation - Skrót UpdateSQL us VtChart vc VSSpell vs WebBrowser wb WebDispatcher wd WebSesion ws WSKAZÓWKA: Niektóre narzdzia typu CASE (komputerowo wspomagana in|ynieria oprogramowania) pozwalaj u|ytkownikowi na zdefiniowane konwencji nazewnictwa, stosowanej dla obiektów automatycznie tworzonych przez program. PrzykBadem takiego narzdzia jest S-Designor (w najnowszej wersji program ten nosi nazw PowerDesignor). W takim przypadku programowi typu CASE mo|na nakaza stosowanie konwencji nazewnictwa, opisanych w niniejszym rozdziale. Nazwy typów Nazwy typów podlegaj tym samym konwencjom, co nazwy komponentów. Wszystkie nazwy typów powinny rozpoczyna si du| liter T. PozostaBa cz[ nazwy powinna mie charakter opisowy, nale|y jednak unika zbyt dBugich nazw, których wielokrotne wpisywanie z klawiatury byBoby uci|liwe. Korzystanie zarówno z du|ych, jak i maBych liter, uBatwia oddzielanie poszczególnych wyrazów w nazwie. W nazwach typów nale|y przestrzega tych samych konwencji, co w nazwach klas - klasy s przecie| tak|e typami. Oto przykBadowa definicja typu: TRecordMouse = (rmAll, rmNone, rmClicksAndDrags); Nazwy staBych Autor przyjmuje i poleca zasad pisania nazw staBych wyBcznie du|ymi literami - podobn reguB przyjto w zapisie nazw staBych (skBadników definiowanych po sBowie #define) w jzyku C. Pozwala ona odró|ni staBe, których warto[ci nie mo|na zmieni, od zmiennych. Poni|ej podano przykBadow deklaracj staBej, zaczerpnit z tekstu zródBowego komponentu LiveQuery, opisanego w rozdziale 27: DEFAULTCREATEVIEWSQL =  CREATE VIEW %s AS  ; Konwencje 97 Nazwy zmiennych W nazwach zmiennych u|ywa si peBnych wyrazów, rozpoczynanych du|ymi literami. Nazwy zmiennych powinny mie charakter opisowy, a jednocze[nie by na tyle krótkie, by daBo si je bez trudu wielokrotnie wpisywa z klawiatury. Oto przykBady dobrze dobranych nazw zmiennych, pochodzcych z tekstu zródBowego komponentu LiveQuery: TemporaryDB : TDatabase; WorkSQL: TStrings; Inna wypróbowana technika polega na dodawaniu na pocztku ka|dej nazwy pojedynczej litery, opisujcej zasig zmiennej:  l dla zmiennej lokalnej,  g - dla globalnej i  c dla zmiennej zwizanej z klas. Przyjcie takiej konwencji uBatwia niekiedy okre[lenie pochodzenia i zasigu zmiennej, bez konieczno[ci analizowania deklaracji funkcji, procedur i klas. Nazwy procedur i funkcji Nazwy procedur i funkcji nale|y konstruowa zgodnie z zasadami obowizujcymi dla nazw zmiennych. Nale|y jedynie, w miar mo|liwo[ci, rozró|nia w nazwie funkcje wymagajce podania argumentów od funkcji bezargumentowych. Poni|szy wiersz programu mo|e by mylcy, gdy| na pierwszy rzut oka nie mo|na zorientowa si, czy SalesTax to zmienna, czy funkcja. x:=SalesTax; Problem ten mo|na rozwiza dodajc przed nazw funkcji bezargumentowych przedrostek Get ( pobierz ). W praktyce okazuje si, |e dobrze jest rozpoczyna nazwy wikszo[ci funkcji od przedrostka Get. Istniej oczywi[cie sytuacje, w których tak skonstruowane nazwy nie maj sensu, jak w przypadku jednej z wbudowanych funkcji Delphi noszcej nazw FileOpen. Dodawanie w tym przypadku przedrostka Get nie miaBoby sensu. W tek[cie zródBowym biblioteki VCL przyjto zasad stosowania przedrostka Set w nazwach procedur, które nadaj nazw atrybutowi, oraz przedrostka Get w tych, które zwracaj warto[ atrybutu. T sam zasad mo|na zastosowa w odniesieniu do procedur i funkcji nie zwizanych z atrybutami. Styl zapisu programu w jzyku Object Pascal Kolejnym obszarem, w którym standaryzacja przynosi wymierne korzy[ci, jest styl zapisu programu. Niemal ka|dy programista stosuje swój wBasny styl zapisu. Okazuje si jednak, |e sam styl jest o wiele mniej istotny ni| konsekwencja w jego stosowaniu. Konsekwencja taka zapewnia czytelno[ programu i uBatwia jego 98 Cz[ I konserwacj. W najbli|szych sekcjach omówimy sposoby zapisu konstrukcji If...else, bloków begin...end oraz komentarzy. Konstrukcja If...else Jedn z reguB, stosowanych z powodzeniem przez autora, jest ujmowanie warunku w konstrukcji If...else w nawiasy. Postpowanie takie jest podwójnie uzasadnione. Po pierwsze - zapewnia lepsz czytelno[ programu. Po drugie - umo|liwia dopisanie drugiego warunku bez konieczno[ci wprowadzania jakichkolwiek zmian w pierwszym. Nale|y podkre[li, |e - w przeciwieDstwie do jzyka C - Pascal nie wymaga ujmowania wyra|eD warunkowych w nawiasy. Dlatego te| poni|szy zapis jest formalnie poprawny: If x=1 then y:=z; Jednak ju| dwa (lub wicej) wyra|enia warunkowe w pojedynczej instrukcji If wymagaj nawiasów: If (x=1) or (x*2=4) then y:=z; Je[li instrukcja If zostaBaby pierwotnie zapisana bez nawiasów, tak jak w pierwszym przykBadzie, to dodajc drugie wyra|enie warunkowe nale|aBoby równie| pamita o ujciu w nawiasy pierwszego wyra|enia. Pascal nie zabrania stosowania nawiasów przy pojedynczych wyra|eniach, dlatego mo|na od pocztku, konsekwentnie ujmowa w nawiasy wszystkie - równie| pojedyncze - wyra|enia warunkowe. Bloki begin...end Inna przyjta przez autora konwencja odnosi si do wszelkich instrukcji, zawierajcych blok programu, ograniczony par begin...end. W szczególno[ci jest to instrukcja warunkowa If...then. SBowo begin umieszczane jest w tym samym wierszu, co instrukcja. W przypadku instrukcji warunkowej oznacza to, |e begin znajdzie si w tym samym wierszu, co If. Pascal nie nakBada |adnych ograniczeD co do rozmieszczenia sBów kluczowych, a zatem begin mo|na umie[ci w dowolnym miejscu - w tym samym wierszu, co if, w wierszu poni|ej albo nawet pi wierszy ni|ej. W ka|dym przypadku kompilator wygeneruje identyczny kod. Oto przykBad zapisu zgodnego z konwencj, proponowan przez autora: if (x=1) then begin y:=z; closefile; Konwencje 99 end; Opinie na temat zapisywania tego rodzaju instrukcji s bardzo zró|nicowane. Niektórzy programi[ci woleliby zapisa t sam instrukcj warunkow nastpujco: if (x=1) then begin y:=z; closefile; end; Metoda ta wi|e si jednak z po[wiceniem dodatkowego wiersza, co bywa szczególnie uci|liwe podczas edycji programu na ekranie. Problem wydaje si istotny z uwagi na ( przyjmowany domy[lnie) maBy rozmiar okna edytora Delphi. Ponadto, zapis ze sBowem begin w oddzielnym wierszu, budzi wtpliwo[ci co do wymaganego wcicia tekstu. Czy sBowo begin, które jest tylko ogranicznikiem bloku, nale|y rozpocz w tej samej kolumnie, co If? Czy te| mo|e powinno by przesunite w prawo wzgldem If, gdy| zawarty w bloku fragment programu jest uzale|niony od If? A co pocz z fragmentem programu midzy begin a end? Czy ma by zapisany równo z begin, czy z If? Proponowany zapis, w którym begin znajduje si w tym samym wierszu, co If, eliminuje problem wcicia. SBowo end peBni oczywist rol terminatora instrukcji If. Wreszcie, fragment programu wykonywany warunkowo, jest przesunity wzgldem If, a nie begin, co uwypukla jego powizanie z warunkiem. Niektórzy programi[ci rozpoczynaj sBowa begin i end du|ymi literami. Nale|y jednak zwróci uwag, |e wszystkie wyrazy pisane wielk liter wyró|niaj si w tek[cie programu. Nie ma to chyba uzasadnienia w przypadku zwykBych ograniczników bloku, które nie s nawet bezpo[rednio tBumaczone na kod maszynowy. Du|e litery nale|y zarezerwowa dla identyfikatorów, wymagajcych szczególnej uwagi (takich jak staBe), a nie sBów begin...end, wystpujcych w ka|dym programie bardzo licznie. Komentarze Object Pascal dopuszcza stosowanie trzech sposobów zapisu komentarzy: (*...*), {...} i //. Do oznaczania zwykBych komentarzy - wyja[niajcych dziaBanie cz[ci programu - najlepiej stosowa symbol {...}. Symboli (*...*) mo|na wówczas u|ywa w procesie testowania programu, do chwilowego wyBczania niektórych fragmentów. Tak zaznaczone fragmenty Batwo mo|na odszuka i ponownie uaktywni albo definitywnie usun. Dla komentarzy, opisujcych pojedynczy wiersz programu, zarezerwowany jest symbol //. 100 Cz[ I Od przyjtych zasad oznaczania komentarzy trzeba odstpi, je[li komentarze maj by zagnie|d|one albo zawiera jeden z wymienionych wy|ej zarezerwowanych symboli. Kompilator zasygnalizuje bBd, je[li w tek[cie komentarza, rozpocztego znakiem {, napotka ponownie ten sam lewy nawias. Je[li komentarz musi zawiera nawiasy {}, to nale|y go oznaczy np. symbolami (* i *). Obiekty zwizane z serwerem bazy danych Stosowanie staBych zasad nazewnictwa obiektów serwera bazy danych pozwala unikn wielu stresów. Tworzenie du|ych baz danych przypomina pisanie du|ych programów - im stosowane nazwy obiektów s czytelniejsze, tym mniejsze jest prawdopodobieDstwo pogubienia si w gszczu elementów. Konsekwentnie nazywane obiekty staj si swoistymi drogowskazami - pomagaj w poruszaniu si po bazie danych. Konsekwentne nazewnictwo nie tylko upraszcza administrowanie baz danych - uBatwia równie| tworzenie czytelnych zapytaD. Jzyk SQL ma przecie| z zaBo|enia przypomina naturalny jzyk mówiony, a jednocze[nie pozostawa jzykiem strukturalnym. ZrozumiaBe i konsekwentnie dobrane nazwy podnosz czytelno[ programów, zapisanych w jzyku SQL. Podobnie jak w przypadku elementów jzyka Object Pascal, tak|e i tutaj wszelkie proponowane konwencje s wyBcznie sugestiami autora. Czytelnicy powinni stosowa takie zasady nazewnictwa, jakie im najbardziej odpowiadaj. Konsekwencja w stosowaniu przyjtych zasad jest znacznie wa|niejsza ni| wybór jakichkolwiek konkretnych reguB. UWAGA: W dalszej cz[ci niniejszej sekcji wielokrotnie natrafi mo|na na sugestie stosowania w ramach jednej nazwy du|ych i maBych liter; ma to sBu|y oddzieleniu poszczególnych wyrazów. Dlatego nale|y - w miar mo|liwo[ci - tak skonfigurowa serwer, aby rozró|niaB on w nazwach du|e i maBe litery. Niektóre serwery (np. InterBase) nie daj takiej mo|liwo[ci. Stosowanie ró|nej wielko[ci liter w nazwach traci wówczas sens. Wprawdzie pisane przez u|ytkownika skrypty SQL s bardziej czytelne, jednak forma zapisu nazw mo|e zosta caBkowicie zignorowana przez serwer. Serwer bazy danych mo|e nie zapamitywa i nie respektowa nazw zawierajcych zarówno du|e, jak i maBe litery. Nawet je[li np. nazwy kolumn tabeli zapisane s du|ymi i maBymi literami, serwer mo|e po ka|dym dostpie do bazy zwraca te same nazwy zapisane wyBcznie du|ymi literami. W takich przypadkach lepiej od razu zapisa nazwy du|ymi literami, a do oddzielania wyrazów stosowa znak podkre[lenia (_). Konwencje 101 Serwery Praktyka dowodzi, |e konsekwencja w nazewnictwie zasobów baz danych, takich jak serwery, jest nie mniej wa|na ni| konsekwencja w nazewnictwie obiektów, udostpnianych przez te zasoby. Autorzy systemów baz danych, zarzdzajcy wieloma podobnymi serwerami, mog unikn pomyBek, stosujc jednolite nazewnictwo serwerów. W prezentowanej tutaj konwencji, nazwy serwerów skBadaj si z o[miu znaków i s zapisywane du|ymi literami. Pierwsze trzy znaki identyfikuj typ serwera: SQL oznacza serwer Sybase lub Microsoft SQL Server, ORA - Oracle Server, SQA - SQL Anywhere, itd. Kolejne trzy znaki sBu| do rozró|nienia serwerów przeznaczonych do tworzenia aplikacji (development), testowania i wBa[ciwych serwerów u|ytkowych (dziaBajcych na rzeczywistych danych, na rzecz rzeczywistych u|ytkowników). Oznaczenia tych serwerów to odpowiednio  DEV ,  TST i  PRO . Ostatnie dwa znaki przeznaczone s na numer kolejny z zakresu od 1 do 99 (numer zerowy jest zarezerwowany - zob. nastpny akapit). Numeracja umo|liwia zaBo|enie wielu wersji tego samego serwera. Omówione zasady najlepiej zilustruje przykBad. ZaBó|my, |e mamy serwer Sybase, który jako jedyny sBu|y do tworzenia aplikacji. Serwer ten nosiB bdzie nazw SQLDEV01. Analogicznie, u|ytkowa wersja tego serwera nazywa si bdzie SQLPRO01. WSKAZÓWKA: Zerowy numer kolejny dobrze jest zarezerwowa dla specjalnych zastosowaD. Mo|na na przykBad utworzy tymczasowy serwer Oracle, u|ywany do budowy aplikacji i nazwany ORADEV00. Podobnie, lokalny serwer Sybase, dziaBajcy na komputerze typu laptop, mo|na nazwa SQLDEV00; z serwera tego z zaBo|enia korzystaB bdzie tylko wBa[ciciel laptopa. Zarezerwowanie numeru zerowego dla specjalnych zastosowaD okazuje si bardzo przydatne w praktyce. UWAGA: Umieszczanie numeru w nazwach serwerów mo|e si wydawa zbdne. Po co wBa[ciwie tworzy wicej ni| jeden egzemplarz serwera okre[lonego typu? Do[wiadczeni administratorzy baz danych znaj odpowiedz na to pytanie. Zarzdzajc zbiorem serwerów, prawie zawsze stan mo|na przed konieczno[ci utworzenia kilku serwerów u|ytkowych lub przeznaczonych do budowania lub testowania aplikacji . Serwery mo|na podzieli ze wzgldu na stosowane aplikacje, jednostki organizacyjne, które z nich korzystaj, wreszcie w celu poprawy wydajno[ci aplikacji. Mo|e si tak|e okaza, |e bezpieczniej jest przeprowadza wszelkie zmiany i uaktualnienia na oddzielnych serwerach, bez nara|ania wBa[ciwych serwerów u|ytkowych. 102 Cz[ I Administrator ka|dego systemu zarzdzania baz danych co jaki[ czas zmuszony jest do przeprowadzania uaktualnienia systemu operacyjnego albo oprogramo- wania serwera bazy danych. Oczywi[cie przeprowadzanie takich zmian wymaga wielkiej ostro|no[ci, gdy| nie mo|e doprowadzi do awarii dziaBajcych systemów. Dlatego przed uaktualnieniem serwera bazy danych zawsze testuje si wszelkie zmiany i nowe wersje oprogramowania. Najcz[ciej administrator przygotowuje nowy komputer, instaluje na nim nowy serwer bazy danych, po czym kopiuje dane ze starego serwera na nowy. Eliminuje to mo|liwo[ zakBócenia pracy dziaBajcego serwera podczas wprowadzania zmian w oprogra- mowaniu systemowym. Bardzo czsto administratorzy uaktualniaj najpierw wBasne serwery, u|ywane do budowy lub testowania aplikacji, a nastpnie zamieniaj je rolami z dotychczasowymi serwerami u|ytkowymi. ZaBó|my, |e administrator bazy danych Oracle chce przeprowadzi uaktualnienie serwera u|ytkowego ORAPRO01, instalujc na nim now wersj systemu zarzdzania baz danych Oracle. W takim przypadku nale|y: 1. Zainstalowa now wersj Oracle na serwerze do tworzenia aplikacji, ORADEV01. 2. Skopiowa rzeczywiste dane na uaktualniony serwer. 3. Po przetestowaniu uaktualnionego serwera z istniejcymi systemami, zmieni jego nazw na ORAPRO02 (gdy| ORAPRO01 nadal istnieje i dziaBa), po czym nakaza wszystkim rzeczywistym aplikacjom korzystanie z ORAPRO02 w miejsce ORAPRO01. W [rodowisku UNIX zmiany takiej mo|na dokona za po[rednictwem mechanizmów nazewnictwa hostów, np. DNS. 4. Po uruchomieniu nowego serwera u|ytkowego mo|na zmieni nazw dotychczasowego - ORAPRO01 - na ORADEV01, gdy| teraz bdzie on u|ywany do tworzenia aplikacji. 5. Ostatnim etapem jest uaktualnienie nowego serwera do tworzenia aplikacji (ORADEV01, poprzednio ORAPRO01). Opisana powy|ej procedura jest najbezpieczniejszym, znanym autorowi, sposobem uaktualnienia oprogramowania systemowego. Alternatyw mo|e by jedynie zaBo|enie caBkowicie nowego serwera bazy danych. Procedur uaktualnienia znacznie upraszcza stosowanie omówionych wcze[niej konwencji nazewnictwa serwerów. (Oczywi[cie podczas uaktualniania systemu nie mo|na oby si bez prawidBowo wykonanych kopii bezpieczeDstwa). Bazy danych Bazy danych, w rozumieniu przyjtym w niniejszej ksi|ce, s zbiorami tabel - nie s to|same z tabelami. Nazwy baz danych nale|y zapisywa maBymi literami. Konsekwencja w zapisie jest w tym przypadku szczególnie istotna, gdy| niektóre Konwencje 103 serwery baz danych w standardowej konfiguracji bior pod uwag wielko[ liter przy rozró|nianiu nazw. Pierwsze trzy znaki nazwy mog stanowi prefiks, identyfikujcy system, do którego nale|y dana baza. Je[li z bazy korzysta kilka oddzielnych aplikacji, to jej nazwa powinna mie bardziej ogólny charakter. Na ogóB celowe jest rozró|nienie baz danych nadrzdnych od baz transakcyjnych. Nadrzdna (ang. master) baza danych zawiera tablice, których zawarto[ zmienia si stosunkowo rzadko, i w których wyszukuje si nazwy i inne informacje o charakterze opisowym. Transakcyjna (ang. transactional) baza danych przechowuje bardziej ulotne dane - jej zawarto[ mo|e zmienia si z dnia na dzieD. Dane transakcyjne s na ogóB wprowadzane z klawiatury przez u|ytkownika albo pobierane z zewntrznych urzdzeD. Niekiedy bazy nadrzdne i transakcyjne tworzone s jako oddzielne obiekty, czasami za[ poBczone s w jedn baz danych. W tym pierwszym przypadku celowe jest nadanie obu bazom odpowiednich, ró|nych nazw. UWAGA: Niektóre platformy systemów zarzdzania bazami danych (np. InterBase) nie dopuszczaj odwoBaD pomidzy tabelami, nale|cymi do ró|nych baz danych. W szczególno[ci oznacza to, |e z tabeli transakcyjnej, nale|cej do jednej bazy danych, nie mo|na odwoBa si do tabeli , znajdujcej si w innej, nadrzdnej bazie danych. Dlatego, przystpujc do planowania organizacji baz danych, nale|y upewni si, czy stosowany system zarzdzania bazami dopuszcza odwoBania do zewntrznych tabel. Je[li system nie pozwala na stosowanie takich odwoBaD, to sugerowane powy|ej oddzielenie nadrzdnych i transakcyjnych baz danych nie bdzie mo|liwe. Niekiedy ostatni znak (lub ostatnie dwa znaki) nazwy bazy danych przeznacza si na numer kolejny. Pozwala to na tworzenie podobnych nazw wielu wersji tej samej bazy. Powy|sza metoda bywa jednak rzadko stosowana w praktyce. W omawianej konwencji nadrzdna baza danych systemu finansowo- ksigowego mogBaby nosi nazw fknad0. fk identyfikuje baz danych jako nale|ca do systemu finansowo-ksigowego, nadrz oznacza, |e jest to baza nadrzdna, a cyfra 0 wskazuje, |e jest to pierwsza z grupy potencjalnie kilku podobnych baz danych. Nale|y ponownie zwróci uwag na ograniczenie dBugo[ci nazwy do o[miu znaków. Istotnym powodem dobrowolnego zastosowania si do tego ograniczenia jest mo|liwo[ nadania skryptowi SQL, przeznaczonemu do tworzenia bazy danych, tej samej nazwy, co samej bazie. Je[li nazwa bdzie ograniczona do o[miu znaków, to nawet skrypt rezydujcy w systemie nie dopuszczajcym dBugich nazw plików, bdzie mógB nosi nazw identyczn z nazw bazy danych. Krótkie nazwy plików s wygodne równie| dlatego, |e nie trzeba ich zmienia wraz z ewentualn zmian platformy. Dlatego wskazane jest ograniczenie dBugo[ci nazw plików 104 Cz[ I równie| wówczas, gdy przechowywane s one na lokalnym dysku (co wi|e si z mo|liwo[ci stosowania dBugich nazw w podsystemie Win32s). Pliki danych Wikszo[ korporacyjnych systemów zarzdzania bazami danych rozró|nia definicje baz danych od urzdzeD, w których dane s fizycznie przechowywane. Jest to realizowane za po[rednictwem konstrukcji programowych znajdujcych si pomidzy bazami danych a napdami dysków, na których te bazy s skBadowane. System SQL serwer odwoBuje si do tych konstrukcji jako do urzdzeD logicznych natomiast w Oracle obiekty takie nazywa si plikami danych (ang. data files). Pliki danych odwoBuj si bezpo[rednio do napdów dyskowych. Z kolei bazy danych zawieraj odwoBania do plików danych. Dziki przyjciu takiego rozwizania, mo|liwe jest przechowywanie jednej bazy danych na kilku ró|nych napdach, a nawet na kilku ró|nych serwerach; nie wymaga to |adnych dodatkowych zabiegów. Omawiane podej[cie zapewnia jednolity interfejs, przeznaczony do tworzenia i rozszerzania baz danych, niezale|ny od ich fizycznej lokalizacji. Na ogóB urzdzeniom logicznym i plikom danych nadaje si nazwy podobne do nazw skojarzonych z nimi baz danych. ReguBa ta wynika ze stosowanej przez autora zasady przechowywania w ka|dym pliku danych tylko jednej bazy. W ramach ka|dej nazwy, pierwsze trzy znaki identyfikuj przeznaczenie urzdzenia. Dalej nastpuje numer sekwencyjny, okre[lajcy pozycj pliku w grupie podobnych plików danych. Nazw urzdzenia koDczy rozszerzenie DAT (dane). Nale|y zwróci uwag, |e pliki urzdzeD s widoczne równie| poza serwerem bazy danych - z poziomu systemu operacyjnego. Nadanie wszystkim plikom danych tego samego rozszerzenia uBatwia odnalezienie ich po[ród wielu innych plików w tym samym katalogu. Omawian konwencj najlepiej zilustruje przykBad. ZaBó|my, |e mamy plik urzdzenia na którym umie[cili[my dane z bazy danych o nazwie medical. Mo|na wtedy pierwsze urzdzenie danych nazwa meddat00.dat. Podobnie, pierwsze urzdzenie z protokoBem (log device) mo|e otrzyma nazw medlog00.dat. Pierwsze trzy znaki identyfikuj baz danych, obsBugiwan przez urzdzenie, kolejne trzy - wBa[ciw funkcj urzdzenia, a numer sekwencyjny okre[la pozycj pliku w[ród podobnych plików urzdzeD. UWAGA: SQL Server pozwala nadawa plikom urzdzeD zarówno nazwy logiczne, jak i fizyczne. Omawiana powy|ej konwencja dotyczy nazw fizycznych. Jako nazwy logicznej mo|na u|y nazwy fizycznej, pozbawionej rozszerzenia. Konwencje 105 Projektanci baz danych czsto dokBadnie definiuj miejsce fizycznego przechowywania poszczególnych tabel i indeksów; kieruj si przy tym wzgldami wydajno[ci systemu. W przypadku systemu SQL Server sBu|y do tego mechanizm segmentów (segments), a w [rodowisku Oracle - mechanizm przestrzeni tablespace. Plik urzdzenia logicznego, który ma by u|ywany wyBcznie przez dany segment bdz przestrzeD tablespace, powinien nosi odpowiedni nazw. Na przykBad, plik skojarzony z segmentem ksiega- przychodowrozch mógBby nosi nazw kprdat00.dat. Powy|szym zasadom przy[wieca idea Batwego rozpoznawania danych, skojarzonych z danym plikiem urzdzenia, wprost z poziomu systemu operacyjnego. UBatwia to odtwarzanie stanu bazy po wszelkich awariach i sporzdzanie kopii zapasowych. Tabele Nazwy tabel nale|y zapisywa wyBcznie du|ymi literami. Tabele s kluczowymi elementami bazy danych, a zapis du|ymi literami wyró|ni je w tek[cie poleceD SQL. Wprawdzie wikszo[ wspóBczesnych systemów zarzdzania bazami jednakowo traktuje nazwy zapisane du|ymi i maBymi literami, jednak proponowany tutaj zapis nazw tabel spowoduje ich wyró|nienie w skryptach SQL i procedurach pamitanych. Same nazwy powinny by jak najprostsze, opisowe i skBada si z jednego lub dwóch sBów, nie przekraczajcych w sumie dBugo[ci o[miu znaków. Nie zaleca si stosowania jakichkolwiek numerów sekwencyjnych. Stosowanie powy|szych zasad ma przyczyni si do uproszczenia zapytaD SQL. Skomplikowane nazwy tabel s trudne do odczytania i zapamitania. Najlepiej sprawdzaj si zatem identyfikatory jednowyrazowe. Oto przykBady prawidBowych nazw tabel: FAKTURY, ZAMOWIEN, KLIENT. Równie| w tym przypadku nale|y zwróci uwag na ograniczenie dBugo[ci nazwy do o[miu znaków. Ograniczenie to pozwoli na nadawanie skryptom SQL nazw identycznych z nazwami tworzonych przez nie tabel - niezale|nie od stosowanego systemu operacyjnego. WSKAZÓWKA: Nadajc tabelom nazwy proste i logiczne, autor systemu bazy danych daje u|ytkownikom szans tworzenia ich wBasnych zapytaD SQL. Dostpnych jest wiele narzdzi do wizualnego konstruowania zapytaD. U|ytkownicy bd mogli z nich skorzysta, je[li tylko nazwy tabel nie bd miaBy zbyt  komputerowego charakteru. 106 Cz[ I Indeksy W wielu dialektach SQL zapytania nie mog zawiera bezpo[rednich odwoBaD do indeksów. Dlatego nazewnictwo indeksów jest stosunkowo maBo istotnym zagadnieniem. Mo|na, na przykBad, nadawa indeksom nazwy identyczne z nazwami tabel, na bazie których powstaBy. Taka nazwa powinna by uzupeBniona numerem, okre[lajcym pozycj danego indeksu wzgldem innych - pierwszy indeks tabeli KLIENT mo|e nazywa si KLIENT01, drugi - KLIENT 02, i tak dalej. Liczby w nazwie odpowiadaj numerowi przypisywanemu przez Sybase SQL Server; dziki nim Batwiej jest pisa efektywne zapytania, wymuszajce stosowanie konkretnego indeksu. Perspektywy (ang. views) Perspektywy nale|y nazywa tak samo, jak tabele. W zapytaniach SQL perspektywy i tabele peBni bowiem t sam rol. Niektórzy programi[ci wyró|niaj perspektywy przez dodanie do nazwy liter V lub VW. Nie jest to jednak konieczne. Procedury i funkcje pamitane Nazwy procedur i funkcji pamitanych dobrze jest zapisywa maBymi literami. UBatwi to odró|nienie ich od nazw tabel i innych obiektów w zapytaniach SQL. Wielko[ liter w nazwach zale|y na ogóB od preferencji programisty, gdy| wiele wspóBczesnych serwerów SQL nie rozró|nia du|ych i maBych liter w nazwach. W ka|dym przypadku zró|nicowanie nazw obiektów przez stosowanie ró|nych wielko[ci liter poprawia czytelno[ zapytaD. Niektórzy programi[ci dodaj litery sp na pocztku lub na koDcu nazwy procedury pamitanej. Na ogóB nie jest to potrzebne. Procedury pamitanej niemal nigdy nie u|ywa si w tym samym kontek[cie, co jakiegokolwiek innego obiektu, np. tabeli. Rzadko na przykBad spotyka si zapis SELECT * FROM nazwaprocedury, a ju| nigdy - EXECUTE nazwatabeli. Osoby, które regularnie stosuj polecenie SELECT z nazw procedury pamitanej, u|ywanej w tym samym kontek[cie, co nazwa tabeli (co jest dozwolone np. na platformie InterBase), mog zdecydowa si na dodawanie sp do nazw procedur pamitanych; w innym przypadku nie ma takiej potrzeby. Konwencje 107 OSTRZE{ENIE: W przypadku platform Sybase oraz Microsoft SQL Server, procedury pamitane, których nazwy rozpoczynaj si od cigu znaków sp_, przechowywane s w nadrzdnej (master) bazie danych. Istnieje wiele powodów, dla których nale|y unika przechowywania obiektów u|ytkownika w bazie danych typu master. Dlatego, decydujc si na dodatkowy wyró|nik nazw procedur pamitanych, nale|y dodawa _sp na koDcu nazwy. Tworzc nazwy procedur pamitanych, mo|na stosowa z powodzeniem te same zasady, które obowizywaBy w nazewnictwie moduBów (units) jzyka Object Pascal. Pierwszy znak identyfikuje zatem aplikacj, do której nale|y procedura. Po nim nastpuje trzy- lub sze[cioliterowy cig, opisujcy ogólne i specyficzne funkcje procedury. Nazw koDczy jedno- albo dwucyfrowy numer kolejny wersji. Zatem procedura, która sporzdza list na podstawie tabeli CALLS w systemie zarzdzania wynajmem (Rental Maintenance Management System), nazywaBaby si RCALLST0. Litera R identyfikuje system, do którego nale|y procedura, CAL wskazuje na zwizek procedury z tabel CALLS, LST oznacza, |e procedura sporzdzi list na podstawie tabeli, a cyfra 0 wskazuje, |e jest to pierwsza procedura z serii kilku podobnych. UWAGA: Systemy Sybase i Oracle dopuszczaj nadawanie jednej bazowej nazwy kilku procedurom pamitanym. W systemie Oracle wybór wBa[ciwej procedury realizuje si wówczas za po[rednictwem mechanizmu przeci|ania. W przypadku systemu Sybase za nazw procedury umieszcza si [rednik i numer kolejny procedury zapamitanej pod dan nazw. Nale|y unika stosowania powy|szych mechanizmów. Bywaj one trudne do opanowania i potencjalne korzy[ci z ich stosowania nie rekompensuj zwizanych z nimi utrudnieD i pomyBek. Pakiety Pakiety, bdce zbiorami procedur i funkcji pamitanych, powinny by nazywane podobnie jak te procedury i funkcje. Nazwy nale|y zapisywa maBymi literami. Pierwszy znak identyfikuje aplikacj, do której nale|y pakiet. Po nim nastpuje trzy- lub sze[cioliterowy cig, opisujcy ogólne i specyficzne funkcje pakietu. Nazwa koDczy si liter p, zajmujc miejsce numeru kolejnego wersji procedury. 108 Cz[ I ReguBy Je[li stosowany serwer obsBuguje reguBy (ang. rules), to nale|y nadawa im nazwy o charakterze opisowym i stosowa zarówno du|e, jak i maBe litery. Nale|y tak|e zdecydowa, czy nadawane nazwy maj okre[la zbiór danych, który reguBa wyklucza, czy te| zbiór, który reguBa dopuszcza., Je[li stosowane nazwy maj okre[la zbiór danych dopuszczalnych, to reguBa wykluczajca wprowadzenie warto[ci zerowej nazywaBaby si NonZero. Analogicznie reguBa, wymuszajca wpisanie w pole PBe jednej z dwóch warto[ci: K albo M, mogBaby si nazywa KobietaMezczyzna. Zapytania SQL rzadko zawieraj bezpo[rednie odwoBania do reguB, dlatego te| ich nazwy nie maj wikszego znaczenia. ReguBy nale| ponadto do obiektów, które rzadko tworzone s przy pomocy oddzielnych skryptów SQL. Nie ma zatem powodu, by ogranicza dBugo[ ich nazw do o[miu znaków. Warto[ci domy[lne Je[li stosowany serwer dopuszcza stosowanie obiektów, reprezentujcych warto[ci domy[lne kolumn, to w ich nazwie nale|y zawrze identyfikator pola, któremu odpowiadaj (je[li odpowiadaj tylko jednemu polu), a tak|e wpisywan przez nie warto[ domy[ln. Nazwy powinny by zapisywane zarówno maBymi, jak i du|ymi literami. Na przykBad, warto[ domy[lna, skojarzona z polem Sex i automatycznie wpisujca w to pole F, powinna nazywa si SexFemale. Zapytania SQL rzadko zawieraj bezpo[rednie odwoBania do warto[ci domy[lnych, dlatego te| ich nazwy s maBo istotne. Warto[ci domy[lne nale| do obiektów, których na ogóB nie tworzy si przy pomocy oddzielnych skryptów SQL. Nie ma zatem powodu, by ogranicza dBugo[ ich nazw do o[miu znaków. Domeny Domeny (definiowane przez u|ytkownika typy danych) peBni rol zbli|on do typów danych w jzyku Object Pascal. Dlatego mo|na stosowa do nich podobne reguBy nazewnictwa. Nazwa domeny powinna pochodzi od nazwy kolumny, której zawarto[ci domena dotyczy. Ponadto na pocztku nazwy domeny nale|y umie[ci liter T, podobnie jak w nazwach typów danych jzyka Object Pascal. Na przykBad, domena definiujca kolumn CustomerNo, nosi bdzie nazw TCustomerNo. Taka nazwa niesie informacj, |e domena definiuje kolumn CustomerNo, a ponadto pozwala w poleceniu CREATE TABLE odró|ni domen od wbudowanych typów danych. Domeny nale| do obiektów, które rzadko tworzone s przy pomocy oddzielnych skryptów SQL. Nie ma zatem powodu, by ogranicza dBugo[ ich nazw do o[miu znaków. Konwencje 109 Wizy i wyjtki Wizy i wyjtki powinny nosi nazwy o formie zbli|onej do komunikatów. Nazwy takie pozwalaj na szybk identyfikacj problemu, który spowodowaB naruszenie wizów albo wygenerowanie wyjtku. U zródeB przyjcia takiej konwencji nazewnictwa le|y konieczno[ poinformowania u|ytkownika o problemie za po[rednictwem samej tylko nazwy obiektu - w przypadku niektórych narzdzi nie mo|na bowiem liczy na przekazanie peBnego komunikatu z serwera (w szczególno[ci dotyczy to komunikatów, dotyczcych naruszenia wizów). Narzdzia te zwracaj ponadto nazwy zapisane du|ymi literami, niezale|nie od formy, w jakiej przechowywane s one w bazie danych. Nale|y zatem unika stosowania w nazwach ró|nej wielko[ci liter. PrzykBadowo ograniczenie klucza obcego, zapewniajce wprowadzenie poprawnego numeru klienta, mogBoby nosi nazw INVALID_CUSTOMER_NO. Je[li nastpi naruszenie ograniczenia, a narzdzie po stronie u|ytkownika przekazuje z serwera przynajmniej nazwy naruszonych wizów, to u|ytkownik uzyska podstawow informacj o zródle problemu. Ta sama zasada powinna obowizywa w nazewnictwie wyjtków, chocia| w tym przypadku mo|na spodziewa si, |e narzdzie interfejsu front-end wy[wietli opis wyjtku, a nie jego nazw. Wizy i wyjtki równie| nale| do obiektów, które rzadko tworzone s przy pomocy oddzielnych skryptów SQL. Nie ma zatem powodu, by ogranicza dBugo[ ich nazw do o[miu znaków. Generatory i sekwencje Podobnie jak nazwy domen, tak|e nazwy generatorów i sekwencji powinny pochodzi od nazw obsBugiwanych kolumn. Na koDcu nazw mo|na doda cig znaków GEN albo SEQ. Generator, obsBugujcy kolumn CustomerNo, bdzie wic nosiB nazw CustomerNoGEN. Sekwencja, skojarzona z kolumn OrderNo, nazywa si bdzie OrderNoSEQ. Generatory i sekwencje nale| do obiektów, których na ogóB nie tworzy si przy pomocy oddzielnych skryptów SQL. Nie ma zatem powodu, by ogranicza dBugo[ ich nazw do o[miu znaków. Kursory Nazwy kursorów odpowiadaj zazwyczaj nazwom tabel, na których operuj. Celowe jest ponadto rozró|nienie kursorów, które umo|liwiaj uaktualnianie danych od kursorów, które takiej mo|liwo[ci nie daj. Rozró|nienie takie mo|na uzyska dodajc do wBa[ciwego identyfikatora sBowo UPDATE (uaktualnienie) albo SELECT (selekcja).Taj wic kursor zadeklarowany dla tabeli TENANT, umo|liwiajcy uaktualnienia i usuwanie rekordów mógBby nazywa si TENANT_UPDATE. Z kolei kursor odwoBujcy, wskazujcy na tabel 110 Cz[ I PROPERTY, i nie pozwalajcy na uaktualnienia danych, nosiBby nazw PROPERTY_SELECT. Procedury zdarzeD (triggers) Nazwy procedur zdarzeD powinny zawiera identyfikatory skojarzonych z nimi tabel oraz poleceD SQL, które powoduj ich uaktywnienie. Procedura zdarzenia mo|e by uaktywniana w trakcie wykonywania komend SQL INSERT, UPDATE albo DELETE, a zatem lista komend uaktywniajcych, zawarta w nazwie, bdzie stanowiBa kombinacj sBów Insert, Update i Delete. I tak procedura zdarzenia uaktywniana po dodaniu lub aktualizacji wiersza w tabeli TENANT bdzie nazywaB si TENANTInsertUpdate, natomiast inna, uaktywniana po usuniciu rekordu z tabeli WORDERS, mogBaby nosi nazw WORDERSDelete. Je[li serwer pozwala zdecydowa, czy procedura zdarzenia (trigger) ma by uaktywniana przed czy po jednym z wymienionych zdarzeD, to nazwa mo|e dodatkowo zawiera modyfikator Before (przed) albo After (po). Na przykBad nazwa PROPERTYBeforeDelete (albo PROPERTY_BEFORE_DELETE) bdzie identyfikowaBa procedure zdarzenia, uaktywnian przed wykonaniem polecenia DELETE na tabeli PROPERTY. Niektóre platformy pozwalaj okre[li, czy procedura zdarzenia odnosi si do wiersza czy ta| do wyra|enia. W takich przypadkach nazw mo|na uzupeBni liter R albo S, np. PROPERTY_BEFORE_ DELETE_S. Taki zapis identyfikuje typ procedury zdarzenia i skojarzon z nim tabel. Procedury zdarzeD (triggers) nale| do obiektów, które rzadko tworzone s przy pomocy oddzielnych skryptów SQL. Nie ma zatem powodu, by ogranicza dBugo[ ich nazw do o[miu znaków. Kolumny Kolumny s najcz[ciej spotykanymi elementami zapytaD SQL, dlatego szczególnie istotne jest nadawanie im nazw o charakterze opisowym. W zapisie nazw kolumn nale|y stosowa zarówno du|e, jak i maBe litery. Nazwy te powinny by Batwe do wymówienia i zapamitania. Je[li konfiguracja serwera zakBada brak rozró|nienia midzy du|ymi a maBymi literami, to poszczególne wyrazy w nazwach kolumn powinny by oddzielone znakiem podkre[lenia. Nie nale|y nadmiernie skraca nazw kolumn - kto[, kto za kilka lat zajmie si konserwacj odpowiedniego programu w jzyku SQL, z pewno[ci doceni peBne, zrozumiaBe nazwy kolumn. Nazwa nie powinna pozostawia wtpliwo[ci co do roli danej kolumny w bazie danych. Kolumny, które reprezentuj te same jednostki w bazie danych, takie jak CustomerNo (numer klienta), powinny nazywa si tak samo Konwencje 111 we wszystkich tabelach. Decydujc si na skracanie jakiego[ elementu nazwy, np. Number albo Address, nale|y zachowa konsekwencj. SBowa Number nie nale|y zapisywa raz jako No w nazwie CustomerNo, a raz jako Num, w nazwie OrderNum. Jako przykBady dobrze skonstruowanych nazw kolumn wymieni mo|na: OrderNo, ShippingAddress, SampleWeight czy AverageWellDepth. WSKAZÓWKA: Jedn z wa|niejszych korzy[ci, pByncych ze stosowania opisowych nazw kolumn, jest mo|liwo[ bezpo[redniego wykorzystania etykiet, automatycznie wygene- rowanych przez narzdzie programistyczne. Je[li na przykBad na formularz Delphi przecignite zostanie pole tabeli, to na formularzu generowana jest automatycznie etykieta odpowiedniej kolumny. Etykieta zawiera od razu nazw pola w bazie danych. Je[li nazwa ta jest zrozumiaBa, to prawdopodobnie automatycznie wygenerowana etykieta bdzie czytelna tak|e dla u|ytkowników programu - nie bdzie trzeba rcznie wpisywa nowej, bardziej opisowej. A zatem opisowe nazwy kolumn nie tylko uBatwiaj orientacj w schemacie bazy danych - przyspieszaj tak|e prac nad aplikacj. W tablicy 4.2 zebrano konwencje nazewnictwa obiektów serwera, omówione w niniejszym rozdziale.

Wyszukiwarka

Podobne podstrony:
roz04 wek2wkhbt2cwbkpwzqp5dvhb6r6kmyrc553o4va
roz04
ROZ04
haasPl roz04

więcej podobnych podstron