Oprócz liczby indeksów istotnym parametrem jest także ich objętość. Im więcej informacji zawierają pola kolumny podlegającej indeksacji, tym większy będzie indeks. Przykładowo, indeks dla pola zawierającego adres będzie zazwyczaj większy niż indeks dla pola z nazwiskiem. Aby uniknąć zbytniego rozrostu indeksów, można zastosować lokalny klucz indeksujący, identyfikujący długie ciągi za pomocą unikalnej liczby całkowitej. Nie zawsze jest to jednak możliwe lub celowe. Gdy podlegająca indeksowaniu kolumna tabeli zawiera ograniczoną liczbę wartości, np. 0 lub 1, zamiast typowego indeksu BTree można zastosować skrócony indeks tzw. bitmapowy. "Obserwując spadek wydajności baz danych, administratorzy zbyt często korzystają z półśrodków. Dla poprawienia wydajności, zamiast tworzyć nowe indeksy czy kupować nowy sprzęt, często wystarczy jedynie skonfigurować bazę w taki sposób, by logi były zapisywane na innych dyskach niż pliki bazy danych" - tłumaczy Paweł Barut, analityk systemowy w ComArch SA w Krakowie.

Inne wymagania, często powtarzane przez klientów, dotyczą formatu danych. Wielu z nich życzy sobie, aby dane były przechowywane w bazie w formacie XML, o którym wiedzą, że jest nowoczesny i przyszłościowy. "Nie negując zalet XML, trzeba zauważyć, że jest to prawdopodobnie najmniej oszczędna z istniejących form zapisu informacji. XML sprawdza się jako format dla skomplikowanych dokumentów, jednak stosowanie go jako formatu danych w relacyjnej bazie danych powoduje więcej problemów niż pożytku. Tym bardziej że współczesne bazy danych są wyposażone w sprawne mechanizmy eksportu danych do formatu XML" - twierdzi Paweł Kuch z firmy Wasko odpowiedzialny za rozwój produktów.

Typowe zaniedbanie na etapie projektowania systemu polega na deklarowaniu nadmiarowych wielkości pól w bazie danych. Wielokrotnie zdarza się, że dla informacji zawierającej najwyżej kilkanaście znaków w bazie danych jest rezerwowane 50 i więcej. Powód? Większość narzędzi programistycznych samodzielnie rezerwuje standardową wielkość pola i najczęściej nikt tego później nie koryguje. Do wybrania drogi na skróty zmusza programistów tempo prac - któż bowiem doceni wysiłek włożony przez nich w optymalizację, gdy w efekcie przekroczą terminy? Na pewno nie będzie to kierownik projektu. Nie będzie to również klient, który najczęściej w ogóle nie jest świadomy problemu. Tymczasem deklarowanie nadmiarowej wielkości pól w bazie danych przekłada się na wielkość zajmowanych przez bazę danych zasobów dyskowych i wyższe wymagania co do wydajności sprzętu, a w konsekwencji wyższe koszty.

Zaskakująco wiele w dziedzinie objętości baz danych zależy od z pozoru nieistotnych decyzji. Najlepszym przykładem jest zastosowanie międzynarodowego, uniwersalnego formatu zapisu znaków - Unicode. Ponieważ w Unicode znaki opisywane są nie jednym, lecz dwoma bajtami danych, użycie go już na starcie powoduje podwojenie objętości bazy danych.

Sztuka pielęgnacji

Tempo przyrostu objętości bazy danych zależy również od kompetencji i nawyków jej administratora. W skrajnych przypadkach te same dane mogą zajmować nawet kilkakrotnie mniej miejsca. Podstawowym parametrem mającym wpływ na obciążenie zasobów dyskowych przez bazę danych jest wielkość pojedynczego bloku danych, zwanego również stroną (page). Blok to jednostka struktury logicznej bazy danych. Jeżeli zapisywana w niej porcja danych jest mniejsza niż zdefiniowana przez administratora wielkość bloku, pozostała część bloku będzie nie wykorzystana i będzie stanowić rezerwę, np. na zmiany w już zapisanych danych. Modyfikacja danych może jednak nigdy nie zostać przeprowadzona, stąd sprawny administrator powinien potrafić wyważyć, jaki rozmiar nadać blokom w tabelach często modyfikowanych, a jaki w tabelach przeznaczonych do jednokrotnego zapisu. W większości baz można ponadto manipulować wielkością wspomnianej wyżej rezerwy, czyli parametrem określającym, do jakiego stopnia blok danych może być wypełniany danymi.