Релационните бази данни са проектирани да съхраняват много редове на таблица. Има цял куп механизми за улесняване на големи маси, като например:
- Индекси на произволна комбинация от полета за ускоряване на търсенето
- Кеширане на страници, така че често използваните страници остават в паметта
- Вертикално разделяне (колонни бази данни) за допълнителна скорост на заявките
- Разширени алгоритми като хеш обединения и групови bys (поне в бази данни, различни от MySQL)
- Използване на множество процесори и дискове за обработка на заявки
Има едно нещо, което е по-трудно при поставянето на данни в една таблица и това е сигурността. И всъщност при някои обстоятелства това е основна грижа и по същество изисква данните да се поставят в отделна таблица. Тези приложения са рядкост.
За да дадете пример за това колко лошо може да бъде съхраняването на данни в множество таблици, представете си, че във вашата система имате един запис на компания и го съхранявате в таблица. Този запис съхранява информация за компанията - нещо като име, адрес, каквото и да е. Обаждането е 100 байта информация.
Във вашата схема има отделна таблица за всяка "компания", така че това е един ред на таблица. Този запис ще се намира на една страница с данни. Една страница с данни може да бъде 16 kbytes, така че губите около 15,9 kbytes, за да съхранявате тези данни. Съхраняването на 1000 такива записи заема 16 мегабайта вместо около 7 страници на стойност (112 кбайта). Това може да бъде значителен удар в производителността.
Освен това с множество таблици вие не вземате предвид предизвикателствата при поддържането на всички таблици и осигуряването на коректността на данните в различните таблици. Актуализациите за поддръжка трябва да се прилагат към хиляди таблици, вместо към шепа.
