Limity dynamicznych pól w systemie

Wprowadzenie

Platforma AMODIT oferuje szerokie możliwości definiowania różnorodnych typów pól na formularzach – od prostych pól tekstowych, przez listy wyboru, aż po złożone pola odnośników czy dokumentów. Jednak każde pole formularza musi zostać odpowiednio zmapowane na struktury w bazie danych, co bezpośrednio wpływa na limity liczby pól, które można utworzyć w konkretnej implementacji.

Zrozumienie mechanizmu mapowania typów pól na struktury bazodanowe jest kluczowe dla efektywnego zarządzania zasobami systemu. Ograniczenia wynikają z limitów technicznych konkretnych silników baz danych – MySQL oraz MS SQL Server – na których może działać AMODIT.

Często dostajemy pytania: „Ile mogę dodać pól do procesu?” Odpowiedź zależy nie tylko od liczby pól, ale przede wszystkim od typu bazy danych (MySQL vs MS SQL) i typów pól które chce się dodać.

Mechanizm reprezentacji pól w bazie danych

Grupy typów pól w AMODIT

AMODIT organizuje wszystkie dostępne typy pól formularza w cztery podstawowe grupy, które odpowiadają typom danych w bazie danych:

• VARCHAR – dla krótkich tekstów i wartości o ograniczonej długości
• TEXT – dla długich tekstów o znacznie większej pojemności
• NUMBER – dla wartości liczbowych oraz referencji do innych rekordów w innych tabelach
• DATETIME – dla dat i czasu

Każda z tych grup ma przypisane konkretne typy pól dostępne w interfejsie projektanta formularzy.

Mapowanie typów pól na grupy bazodanowe

Poniższa tabela przedstawia szczegółowe przypisanie typów pól do grup:

Grupa	Typy pól obsługiwane przez grupę
Varchar	Krótki tekst, Pole walidowane, Hiperłącze, Lista wyboru, Odnośnik do źródła zewnętrznego, Wyszukiwanie elementu listy SharePoint (przestarzałe), Wartość elementu listy SharePoint (przestarzałe)
Text	Długi tekst, Tabela
Number	Liczba, Kwota, Słownik, Tak/Nie, Użytkownik, Podpis, Odnośnik, Dokument
DateTime	Data, Data i czas

Uwaga: Następujące typy pól nie mają fizycznej reprezentacji w bazie danych i nie wpływają na limity liczby kolumn: Statyczny tekst, Strona zewnętrzna, Tabela SQL, Kod kreskowy, Puste, Raport osadzony, Przycisk, Wywołanie metody webservice (przestarzałe).

Różnice w implementacji między wersjami AMODIT

Sposób mapowania grup na konkretne typy kolumn w bazie danych różni się w zależności od:

• Silnika bazy danych (MySQL vs MS SQL Server)
• Wersji systemu AMODIT

Implementacja w starszych wersjach AMODIT

Nazwa	MySQL	MS SQL
VARCHAR	varchar(255)	nvarchar(256)
TEXT	text	nvarchar(max)
NUMBER	decimal(14,4)	decimal(14,4)
DateTime	datetime	datetime

Implementacja w nowszych wersjach AMODIT

Nazwa	MySQL	MS SQL
VARCHAR	mediumtext	nvarchar(max)
TEXT	text	nvarchar(max)
NUMBER	decimal(14,4)	decimal(14,4)
DateTime	datetime	datetime

Znaczenie zmian w nowszych wersjach

Najważniejszą zmianą między wersjami jest sposób implementacji grupy VARCHAR:

• W starszych wersjach używany był typ varchar(255) i nvarchar(256) co znacząco wpływało na limity liczby pól tego typu w bazie danych
• W nowszych wersjach: zastąpienie typami mediumtext (MySQL) i nvarchar(max) (MS SQL) znacznie zmieniło kalkulację limitów liczby pól

Ta zmiana ma znaczenie dla możliwości definiowania pól z grupy VARCHAR w systemie – umożliwia utworzenie znacznie większej liczby pól typu VARCHAR niż w starszych wersjach.

Instalacje „mieszane” – współistnienie starych i nowych typów

Aktualizacja systemu AMODIT do nowszej wersji nie zmienia już istniejących pól VARCHAR. Zmiana dotyczy tylko sytuacji zwiększania limitu pól. Utworzenie nowych kolumn w bazie danych odbywa się już z użyciem nowego typu np. mediumtext.

Praktyczne konsekwencje:

• Kolumny VARCHAR utworzone przed aktualizacją: nadal pozostają jako varchar(255) (MySQL) lub nvarchar(256) (MS SQL Server)
• Kolumny VARCHAR dodawane po aktualizacji: są tworzone jako mediumtext (MySQL) lub nvarchar(max) (MS SQL Server)

Rezultat: W jednej instalacji AMODIT mogą współistnieć kolumny bazodanowe w różnych formatach – część pól wykorzystuje starą reprezentację, a część nową reprezentację. Oznacza to, że rzeczywiste możliwości konkretnej instalacji zależą od:

• Kiedy została przeprowadzona aktualizacja systemu
• Ile pól VARCHAR było już utworzonych przed aktualizacją
• Ile nowych pól VARCHAR zostało dodanych po aktualizacji

Limity typów pól w AMODIT

Ograniczenia na poziomie systemu AMODIT

Obecnie AMODIT nie ma wbudowanego ograniczenia liczby dodawanych kolumn. System pozwala na dodawanie pól aż do momentu osiągnięcia limitów technicznych bazy danych. W momencie gdy baza nie będzie w stanie dodać nowej kolumny, zostanie to zakomunikowane użytkownikowi poprzez komunikat błędu.

Ta zasada oznacza, że głównym czynnikiem ograniczającym są limity techniczne silnika bazy danych – nie mechanizmy kontrolne AMODIT.

MySQL – Ograniczenia i możliwości

Podstawowe limity MySQL (InnoDB)

Limit	Wartość	Opis
Kolumny w tabeli	1017 kolumn	Wszystkie kolumny łącznie (systemowe + dynamiczne)
Rozmiar rekordu	dane inline ≤ 8 126 B	To co może zostać zapisane w ramach jednego rekordu głównego

Rozmiary typów pól w MySQL

Starsze instalacje AMODIT na MySQL:

Typ pola	Rozmiar w rekordzie	Uwagi
VARCHAR(255)	765 bajtów	UTF-8: każdy znak = 3 bajty × 255
TEXT	20 bajtów	Wskaźnik do treści przechowywanej osobno
DECIMAL(14,4)	7 bajtów	Standardowy NUMBER w AMODIT
DATETIME	5 bajtów	Stała wielkość

Nowsze instalacje AMODIT na MySQL (MEDIUMTEXT):

Typ pola	Rozmiar w rekordzie	Uwagi
MEDIUMTEXT	22 bajty	Wskaźnik do treści przechowywanej osobno
TEXT	22 bajty	Wskaźnik do treści przechowywanej osobno
DECIMAL(14,4)	7 bajtów	Standardowy NUMBER w AMODIT
DATETIME	5 bajtów	Stała wielkość

MS SQL Server – Ograniczenia i możliwości

Podstawowe limity MS SQL Server

Limit	Wartość	Opis
Kolumny w tabeli	1024 kolumny	Wszystkie kolumny łącznie (systemowe + dynamiczne)
Rozmiar rekordu	8060 bajtów	To co może zostać zapisane w ramach jednego rekordu głównego

Rozmiary typów pól w MS SQL Server

Starsze instalacje AMODIT na MS SQL:

Typ pola	Rozmiar w rekordzie	Uwagi
NVARCHAR(256)	512 bajtów	2 bajty na znak (Unicode) × 256 znaków
NVARCHAR(MAX)	max 24 bajty	MS SQL Server automatycznie zarządza przechowywaniem w ROW_OVERFLOW_DATA
DECIMAL(14,4)	9 bajtów	Standardowy NUMBER w AMODIT
DATETIME	8 bajtów	Stała wielkość

Nowsze instalacje AMODIT na MS SQL (NVARCHAR(MAX)):

Typ pola	Rozmiar w rekordzie	Uwagi
NVARCHAR(MAX)	max 24 bajty	MS SQL Server automatycznie zarządza przechowywaniem w ROW_OVERFLOW_DATA
NVARCHAR(MAX)	max 24 bajty	Jak wyżej – oba typy używają tego samego mechanizmu
DECIMAL(14,4)	9 bajtów	Standardowy NUMBER w AMODIT
DATETIME	8 bajtów	Stała wielkość

Mechanizmy optymalizacji przechowywania danych

Dlaczego proste kalkulacje nie działają

Oba silniki baz danych – MySQL InnoDB i MS SQL Server – implementują zaawansowane mechanizmy automatycznego zarządzania przechowywaniem danych, które sprawiają, że tradyjne kalkulacje typu „rozmiar pola × liczba pól = wykorzystanie przestrzeni” nie odzwierciedlają rzeczywistości.

Mechanizmy overflow w MySQL InnoDB

MySQL InnoDB wykorzystuje overflow pages (strony przepełnienia). Baza MySQL z której korzysta AMODIT skonfigurowana jest w formacie DYNAMIC co oznacza może przechowywać całe długie kolumny w overflow pages, pozostawiając tylko 20-bajtowy wskaźnik w rekordzie głównym

Kluczowa zasada: gdy rekord staje się zbyt długi, MySQL automatycznie wybiera najdłuższe kolumny i przenosi je do overflow pages, aż rekord główny zmieści się w limicie strony (~8KB).

Mechanizmy overflow w MS SQL Server

MS SQL Server używa ROW_OVERFLOW_DATA allocation units:

• Kolumna NVARCHAR(MAX) i podobne są automatycznie przenoszone do osobnych stron gdy rekord przekracza 8060 bajtów
• W rekordzie głównym pozostaje 24-bajtowy wskaźnik do rzeczywistych danych
• MS SQL inteligentnie zarządza tym, które kolumny przenieść, aby zoptymalizować wydajność

Praktyczne implikacje dla AMODIT

Co to oznacza dla planowania procesów:

1. Nie można stosować prostych kalkulacji typu „10 pól VARCHAR × 765 bajtów = przekroczenie limitu”
2. Oba silniki baz danych automatycznie optymalizują przechowywanie danych bez ingerencji użytkownika
3. Rzeczywiste limity są znacznie wyższe niż wynikałoby z teoretycznych kalkulacji rozmiaru rekordu
4. Głównym ogranicznikiem staje się limit liczby kolumn (1017 dla MySQL, 1024 dla MS SQL) a nie rozmiar rekordu

Najlepsze praktyki zarządzania polami w AMODIT

Zasada nieodwracalności dodawania pól

Kluczowa zasada: W AMODIT nie ma możliwości „cofnięcia” dodania kolumny. Oznacza to, że:

• Raz dodanej kolumny nie da się usunąć z bazy danych
• Nie można zamienić istniejącej kolumny na inny typ
• Kolumny pozostają w bazie danych na stałe, nawet jeśli pole zostanie usunięte z formularza

Strategiczne podejście do dodawania pól

Ze względu na nieodwracalność procesu, trzeba być niezwykle rozważnym przy dodawaniu i rozszerzaniu zakresu kolumn:

❌ Błędne podejście:

• Dodawanie pól „masowo”, np. 20 kolumn jednego typu „na zapas”
• Tworzenie pól „na wyrost” bez konkretnego zastosowania
• Eksperymentowanie z różnymi typami pól w środowisku produkcyjnym

✅ Prawidłowe podejście:

• Dodawanie tyle pól ile jest potrzebnych w danym momencie (np. 1 lub 2)
• Dokładne zaplanowanie struktury formularza przed implementacją
• Testowanie różnych opcji w środowisku deweloperskim
• Postupowe rozszerzanie funkcjonalności w miarę rzeczywistych potrzeb

Planowanie długoterminowe

Rekomendacje dla administratorów:

1. Analiza wymagań – dokładne określenie potrzeb biznesowych przed dodawaniem pól
2. Dokumentacja struktury – prowadzenie rejestru dodanych pól i ich przeznaczenia
3. Monitoring wykorzystania – regularne sprawdzanie które pola są rzeczywiście wykorzystywane
4. Środowisko testowe – zawsze testowanie nowych struktur przed wdrożeniem na produkcji
5. Backup przed zmianami – zabezpieczenie danych przed każdą większą modyfikacją struktury

Wnioski – zaawansowane mechanizmy optymalizacji baz danych

Analiza limitów pól w systemie AMODIT ujawnia, że obie wykorzystywane bazy danych – MySQL InnoDB oraz MS SQL Server – posiadają zaawansowane mechanizmy zarządzania zajętością rekordu, które automatycznie optymalizują balans między pojemnością danych, wydajnością oraz zajętością przestrzeni dyskowej.

MySQL InnoDB stosuje overflow pages (przechowywanie off-page) z różnymi formatami rekordów (COMPACT, DYNAMIC, COMPRESSED), gdzie długie kolumny VARCHAR, TEXT i BLOB są automatycznie przenoszone do osobnych stron z pozostawieniem 20-bajtowych wskaźników w rekordzie głównym.

MS SQL Server wykorzystuje analogiczne mechanizmy ROW_OVERFLOW_DATA allocation units oraz LOB_DATA pages, automatycznie przenosząc kolumny NVARCHAR(MAX), VARCHAR(MAX) i podobne do osobnych stron z 24-bajtowymi wskaźnikami gdy rekord przekracza limit 8060 bajtów.

Dodatkowo obie bazy implementują intelligent column selection (inteligentny wybór kolumn do przeniesienia), adaptive compression (adaptacyjną kompresję), dynamic threshold management (dynamiczne zarządzanie progami) oraz page-level optimization (optymalizację na poziomie stron). Te mechanizmy sprawiają, że praktyczne limity liczby pól w nowszych wersjach AMODIT są znacznie wyższe niż wynikałoby to z prostej kalkulacji rozmiaru rekordu, umożliwiając tworzenie procesów z setkami pól tekstowych bez znaczącego wpływu na wydajność systemu.

Kluczowe wnioski praktyczne:

• Limity są określane przez silnik bazy danych, nie przez system AMODIT
• Mechanizmy overflow umożliwiają znacznie większą liczbę pól niż sugerowałyby teoretyczne kalkulacje
• Nieodwracalność dodawania pól wymaga przemyślanego podejścia do projektowania struktur
• Dostępne narzędzia (AMODIT DatabaseAdmin) umożliwiają optymalizację istniejących instalacji
• Najlepsze praktyki zarządzania polami są kluczowe dla długoterminowej efektywności systemu