Projekt 4D w architekturze: kompletny przewodnik

Projektowanie architektoniczne 4D to proces tworzenia struktury bazy danych 4D (jej tabel, pól, relacji, indeksów i poziomów dostępu), tak aby aplikacja pozostawała szybka, łatwa w utrzymaniu i bezpieczna w miarę rozwoju. Dobrze zaplanowany schemat 4D zazwyczaj obejmuje pięć podstawowych decyzji: szczegółowość tabeli, strategię relacji, typ klucza podstawowego, lokalizację indeksu i oddzielenie danych od logiki interfejsu. Właściwe wykonanie tego od samego początku pomoże Ci uniknąć kosztownych migracji w przyszłości.

Kluczowe wnioski

• Projekt architektury 4D oddziela trzy obszary: model danych (tabele, pola, relacje), warstwę logiki biznesowej (metody, klasy, wyzwalacze) i warstwę prezentacji (formularze, pola list, okna dialogowe).
• Typ relacji ma większe znaczenie niż liczba tabel: łącze wiele do wielu wymaga tabeli skrzyżowań, podczas gdy łącze jeden do wielu wykorzystuje pole klucza obcego plus relację.
• Indeksy przyspieszają odczyt, ale spowalniają zapis — indeksuj klucze obce i dowolne pole użyte w klauzuli WHERE zapytania, a nie każde pole.
• Warstwa ORDA (Object Relational Data Access) 4D zmienia sposób myślenia o schemacie: dobrze nazwane tabele i pola stają się czytelnymi nazwami klas danych i atrybutów w kodzie.
• Wdrożenie klient-serwer w porównaniu z pojedynczym użytkownikiem to decyzja dotycząca architektury, a nie refleksja nad wdrożeniem — wpływa ona na blokowanie, buforowanie i sposób pisania zapytań.
• Konwencje nazewnictwa stosowane konsekwentnie od pierwszego dnia oszczędzają więcej czasu na refaktoryzację niż jakikolwiek inny pojedynczy nawyk.

Co oznacza „architektura 4D” w kontekście bazy danych

Projekt architektury 4D odnosi się do projektu strukturalnego aplikacji zbudowanej na platformie 4D (4th Dimension), relacyjnej bazie danych i środowisku programistycznym o niskim kodzie, pierwotnie wydanym przez zespół Laurenta Ribardière’a w 1984 roku i obecnie utrzymywanym przez 4D SAS. W przeciwieństwie do czystej bazy danych SQL, 4D łączy silnik danych, język programowania, projektant formularzy i serwer WWW/REST w jeden produkt — zatem „architektura” obejmuje tutaj zarówno schemat, jak i znajdujące się na nim warstwy aplikacji.

Termin ten bywa mylony z wizualizacją architektoniczną (4D BIM, czas jako czwarty wymiar w projektowaniu budynków). Ten przewodnik omawia sens oprogramowania: jak rozmieścić bazę danych 4D i jej warstwy aplikacji. Jeśli szukasz informacji o projektowaniu budynków, poniższe koncepcje nie mają zastosowania.

Trzy warstwy aplikacji 4D

Projekty architektury 4D korzystają z wyraźnego modelu warstwowego. Podział obowiązków zapobiega przekształceniu rozwijającej się aplikacji w plątaninę skryptów formularzy.

Warstwa 1 — Model danych

Model danych to zbiór tabel, pól, relacji i indeksów przechowywanych w pliku struktury 4D. Warstwa ta nie powinna zawierać żadnego kodu interfejsu użytkownika ani żadnych reguł biznesowych, które mogłyby obowiązywać gdzie indziej. Typy pól (tekst, liczba całkowita, liczba rzeczywista, data, godzina, wartość logiczna, blob, obiekt, obraz) i długości pól są tutaj stałe, a ich późniejsza zmiana w działającej bazie danych wymaga ostrożności.

Warstwa 2 — logika biznesowa

Logika biznesowa żyje w metodach projektu, klasach i wyzwalaczach tabel. We współczesnym 4D klasy (wprowadzone w 4D v18 R3 i od tego czasu rozszerzone) pozwalają pisać testowalny kod wielokrotnego użytku, zamiast rozpraszać logikę pomiędzy metodami formularzy. Wyzwalacz na tabeli jest uruchamiany podczas tworzenia, zapisywania i usuwania — jest to przydatne w przypadku ścieżek audytu, ale wyzwalacz wywołujący interfejs użytkownika ulegnie awarii w kontekstach serwera headless.

Powiązane: Airtable — Prosty interfejs arkusza kalkulacyjnego oparty na prawdziwej relacyjnej bazie danych, z automatyzacją, widokami i udostępnianymi interfejsami..

Warstwa 3 — Prezentacja

Prezentacja obejmuje formularze, pola list, okna dialogowe wejściowe i dowolne dane wyjściowe w Internecie lub REST. Formularze 4D wiążą się bezpośrednio z polami i zmiennymi, co jest wygodne, ale zachęca do stosowania logiki w formularzu. Utrzymywanie cienkich metod formularzy — wywoływanie metod klasowych i wyświetlanie wyników — to największa zaleta w zakresie łatwości konserwacji w większości projektów 4D.

Projektowanie modelu danych: tabele, relacje i klucze

Decyzje dotyczące modelowania danych w projektowaniu architektury 4D opierają się na zasadach relacyjnych, z nałożonymi warstwami mechaniki specyficznej dla 4D.

Wybieranie szczegółowości tabeli

Tabela powinna reprezentować jeden typ jednostki. Podział tabeli „klient” na „klient” i „adres_klienta” ma sens, gdy klient może mieć kilka adresów; łączenie ich ma sens, gdy na klienta przypada dokładnie jeden adres i nie ma możliwości ponownego wykorzystania. Nadmierna normalizacja do wielu małych tabel zwiększa liczbę relacji i złączeń, co obniża wydajność w widokach list.

Jeśli robisz zakupy: Zoho Creator — Narzędzie do tworzenia aplikacji o niskim kodzie, które łączy się z szerszym pakietem Zoho i oferuje ceny za użytkownika, a nie za aplikację..

Typy relacji

4D obsługuje relacje automatyczne zdefiniowane w edytorze konstrukcji oraz relacje ręczne utworzone w kodzie. Typowe wzorce:

Relacja	Realizacja 4D	Typowe zastosowanie
Jeden do wielu	Pole klucza obcego po stronie „wiele” plus relacja	Faktura → Linie faktury
Wiele do wielu	Tabela łącząca z dwoma kluczami obcymi	Produkty ↔ Dostawcy
Jeden do jednego	Wspólny klucz podstawowy lub unikalny klucz obcy	Użytkownik → Profil użytkownika
Odniesienie do siebie	Klucz obcy wskazujący z powrotem do tej samej tabeli	Pracownik → Menedżer

Strategia klucza podstawowego

4D oferuje automatyczne zwiększanie długich kluczy głównych i kluczy podstawowych UUID (tekstowych). Klucze Longint są kompaktowe i można je szybko indeksować; Klucze UUID są globalnie unikalne, co ma znaczenie podczas łączenia danych z wielu witryn lub synchronizacji z systemami zewnętrznymi. Typowym kompromisem jest długi klucz wewnętrzny plus oddzielne, unikalne pole tekstowe „zewnętrznego odniesienia”.

Indeksowanie i wydajność zapytań

Indeksy są najskuteczniejszym narzędziem poprawy wydajności w projektowaniu architektury 4D, a także najłatwiejszą do nadmiernego zastosowania.

Co indeksować

Indeksuj dowolne pole używane jako klucz obcy relacji, dowolne pole często używane w kryteriach wyszukiwania zapytania oraz dowolne pole używane do sortowania w dużych listach. 4D obsługuje standardowe indeksy B-drzewa, indeksy słów kluczowych do wyszukiwania tekstu opartego na słowach oraz indeksy złożone obejmujące wiele pól.

Czego nie indeksować

Każdy indeks zwiększa koszt zapisu i miejsce na dane. Indeksowanie pola logicznego z dwiema możliwymi wartościami rzadko pomaga. Indeksowanie pola, które jest zawsze odczytywane tylko w ramach wyświetlania pełnego rekordu, zwiększa obciążenie i nie przynosi korzyści. Przejrzyj indeksy, gdy aplikacja będzie miała rzeczywiste wzorce użycia, zamiast zgadywać z góry.

Strategia zapytań

Zapytania ORDA (ds.Invoice.query("Status = :1"; "Open")) są generalnie lepsze od klasycznych poleceń QUERY dla nowego kodu, ponieważ zwracają wybrane elementy, które można sortować, filtrować i przekazywać między metodami bez ponownego wysyłania zapytań. W przypadku bardzo dużych tabel ograniczenie zapytania za pomocą kryteriów indeksowanych przed zastosowaniem filtrów nieindeksowanych zapewnia przewidywalność czasów odpowiedzi.

Powiązane: Knack — Niewymagający kodu kreator baz danych, przeznaczony dla portali, katalogów i narzędzi wewnętrznych – z cenami ryczałtowymi zamiast opłat za użytkownika..

ORDA i nowoczesna architektura 4D

ORDA (Object Relational Data Access) to obiektowa warstwa dostępu do danych 4D, wprowadzona w 4D v17. Udostępnia tabele jako klasy danych, a rekordy jako jednostki, więc tabela o nazwie Faktura staje się ds.Invoice, a pole o nazwie TotalNet staje się $invoice.TotalNet.

Ma to konsekwencje architektoniczne dla projektu architektury 4d: nazwy tabel i pól są teraz częścią publicznego interfejsu API. Zmiana nazwy pola psuje kod w sposób widoczny w czasie kompilacji, ale niespójne nazewnictwo sprawia, że ​​kod ORDA jest trudny do odczytania. Przyjęcie konwencji – pojedyncze nazwy tabel, pola PascalCase, brak skrótów – procentuje natychmiast.

ORDA obsługuje również selekcje encji po stronie klienta, który jest tylko częściowo załadowany, co zmienia profil wydajności ekranów list. Pole listy powiązane z wyborem encji może wyświetlać tysiące wierszy bez ładowania każdego rekordu, zakładając, że zapytanie znajdujące się za nim jest indeksowane.

Nasz wybór: Claris FileMaker Pro — Długotrwała platforma relacyjnych baz danych dla zespołów, które potrzebują niestandardowych aplikacji na komputery stacjonarne, w Internecie i na urządzeniach mobilnych w jednym pliku..

Wdrożenie klient-serwer, dla jednego użytkownika i w sieci Web

Topologia wdrożenia kształtuje projekt architektury 4D w większym stopniu, niż spodziewa się wielu programistów.

Aplikacje dla jednego użytkownika obsługują silnik danych i interfejs w jednym procesie. Blokowanie jest banalne; dostrajanie wydajności dotyczy głównie szybkości dysku lokalnego.

Klient-serwer oddziela serwer 4D (silnik danych) od klienta 4D (interfejs). Rekordy są zablokowane na serwerze, a koszt sieci w obie strony każdego zapytania staje się znaczny. Architektury generujące wiele małych zapytań na ekran radzą sobie tutaj źle; grupowanie zapytań i korzystanie z wyborów jednostek zmniejsza liczbę podróży w obie strony.

Wdrożenie sieciowe i REST udostępnia ten sam model danych za pośrednictwem serwera REST firmy 4D lub skompilowanych metod sieciowych. Bezpieczeństwo wysuwa się na pierwszy plan: dostęp do tabel i pól musi być ograniczony poprzez role i uprawnienia, a każda reguła biznesowa wymuszona tylko w metodzie formularza jest w rzeczywistości nieegzekwowana w przypadku klientów internetowych.

Konwencje nazewnictwa i dokumentacja

Konsekwentne nazewnictwo jest nieestetyczne, ale decydujące dla projektowania architektury 4D. Praktyczna konwencja dla 4D:

• Tabele: Rzeczowniki w liczbie pojedynczej, PascalCase („Klient”, „InvoiceLine”).
• Pola: PascalCase, bez prefiksów typu („InvoiceDate”, a nie „dInvDate”).
• Relacje: nazwane zgodnie z tabelą docelową („Faktury_Klienta”).
• Metody: najpierw czasownik („Utwórz fakturę”, „Przelicz sumę”).
• Klasy: Najpierw rzeczownik („InvoiceService”, „TaxCalculator”).

Dokumentowanie schematu — nawet w postaci pojedynczego pliku Markdown zawierającego listę każdej tabeli, jej przeznaczenia i kluczowych relacji — znacznie ułatwia wdrożenie i przyszłe migracje. Edytor struktury 4D pokazuje relacje graficznie, ale nie wyjaśnia dlaczego tabela istnieje.

Typowe błędy w projektowaniu architektury 4D

Umieszczanie logiki biznesowej w metodach formularzy. Metod formularzy nie można wywoływać z kontekstów internetowych ani zaplanowanych zadań, więc logika tam uwięziona musi zostać zduplikowana.

W całym nowym kodzie zastosowano klasyczne polecenia oparte na selekcji. Klasyczne selekcje są powiązane z procesami i nie przenoszą się między procesami; Wybór jednostek ORDA jest bardziej elastyczny.

Pomijanie tabeli skrzyżowań. Przechowywanie wielu wartości w jednym polu tekstowym (identyfikatory oddzielone przecinkami) utrudnia indeksowanie i sprawia, że ​​raportowanie jest bolesne.

Indeksowanie wszystkiego. Wydajność zapisu spada, a korzyści rzadko są zauważalne.

Ignorowanie uprawnień do czasu wdrożenia. Dopasowanie modelu zabezpieczeń do gotowej aplikacji jest znacznie trudniejsze niż zaprojektowanie go zgodnie ze schematem.

Jak podjąć decyzję: praktyczna lista kontrolna

Przed zbudowaniem projektu architektury 4d przeanalizuj następujące pytania:

1. Ilu jednoczesnych użytkowników i czy będą się łączyć przez sieć LAN, WAN czy Internet?
2. Które encje mają naturalną relację jeden do wielu, a które wymagają tabel skrzyżowań?
3. Które pola pojawią się w kryteriach wyszukiwania lub kolejności sortowania przy dużych tabelach?
4. Które reguły biznesowe muszą obowiązywać niezależnie od punktu wejścia (formularz, sieć, import)?
5. Czy kiedykolwiek dane zostaną scalone z innym systemem wymagającym kluczy UUID?
6. Kto będzie to utrzymywał za dwa lata i czy to nazewnictwo będzie dla niego miało sens?

Odpowiedzi na te sześć pytań determinują większość decyzji konstrukcyjnych w projekcie 4D.

Dalsze czytanie

Oficjalna dokumentacja 4D na stronie developer.4d.com szczegółowo opisuje ORDA, klasy, przywileje i wdrażanie. Aby zapoznać się z podstawami modelowania relacyjnego, które mają zastosowanie niezależnie od platformy, zobacz artykuł w Wikipedii na temat normalizacji baz danych. W szerszym kontekście platform programistycznych o niskim kodzie i szybkim tworzeniu aplikacji rozsądnym punktem wyjścia jest wpis Wikipedii dotyczący platform programistycznych o niskim kodzie. 4D SAS publikuje także informacje o wydaniu i przewodniki po migracji, które opisują, kiedy wprowadzono ORDA, klasy i inne funkcje projektowania architektury 4d.

Często zadawane pytania

Co to jest projektowanie architektury 4D?

Projektowanie architektury 4D to proces planowania struktury aplikacji 4D (4. wymiar): jej tabel, pól, relacji, indeksów, warstwy logiki biznesowej i warstwy prezentacji. Określa, jak aplikacja działa, jak łatwo można ją zmienić i jak bezpiecznie można ją wdrożyć na komputerze stacjonarnym, kliencie-serwerze lub kliencie internetowym.

Czy architektura 4D to to samo, co 4D BIM?

Nie. 4D BIM dodaje czas jako czwarty wymiar modelowania informacji o budynku na potrzeby planowania budowy. Architektura 4D w sensie programowym odnosi się do projektowania aplikacji na platformie bazodanowej 4D. Obydwa pola mają wspólny skrót, ale nic poza tym.

Czy powinienem używać poleceń ORDA czy klasycznych poleceń 4D?

ORDA to najlepsza opcja dla nowych inwestycji. Zwraca wybrane elementy, które można przekazywać między metodami, sortować i filtrować bez konieczności ponownego sprawdzania, a także udostępnia tabele i pola jako właściwości czytelnych obiektów. Klasyczne polecenia oparte na wyborze są nadal przydatne w starszym kodzie i w niektórych specjalnych przypadkach.

Ile indeksów powinna mieć tabela 4D?

Nie ma stałego numeru. Indeksuj klucze obce, pola używane w typowych kryteriach wyszukiwania i pola używane do sortowania dużych list. Unikaj indeksowania pól o niskiej liczności, takich jak wartości logiczne lub pola stanu z dwiema lub trzema wartościami, ponieważ koszt zapisu zwykle przewyższa korzyści z odczytu.

Jaki typ klucza podstawowego wybrać w 4D?

Klucze longint z automatyczną inkrementacją są kompaktowe i szybkie i nadają się do zastosowań w jednej lokalizacji. Klucze tekstowe UUID są większe, ale globalnie unikalne, co ma znaczenie przy łączeniu danych z wielu witryn lub integracji z systemami zewnętrznymi. Wiele projektów używa wewnętrznie klucza longint oraz unikalnego zewnętrznego pola odniesienia.

Czy mogę zmienić model danych 4D po wdrożeniu?

Tak, ale z ostrożnością. Dodawanie tabel, pól i indeksów jest zazwyczaj proste. Zmiana typów pól, zmiana nazw pól używanych przez kod ORDA lub przebudowa relacji w działającej bazie danych wymaga zaplanowanej migracji, najlepiej przetestowanej najpierw na kopii danych produkcyjnych.