По-перше, твердження «Все в одну таблицю» відносилося лише
до списку нерухомості. Поміщати в цю таблицю що то крім
нерухомості не треба :)
Наведу посилання з Хабра ж.
«B-tree Операція пошуку виконується за час O (t logt n), де t -
мінімальна ступінь. Важливо тут, що дискових операцій ми
здійснюємо всього лише O (log t n)! »
Логарифм значить, що при при збільшенні бази даних в 2 рази,
час пошуку возрасает лише на одну операцію порівняння
(Або дискову операцію, хоча це не завжди так).
Ось і виходить, що б знайти потрібну запис серед 1.000.000 записів
витрачається 0.1 сек. А серед 2.000.000 записів (в одній таблиці)
витрачається 0.101 сек.
Якщо ми будемо шукати в двох таблицях по 1.000.000 записів, то відповідно
у нас піде 0.2 сек.
1000, 500, 250, 125, 65, 33, 17, 8, 4, 2, 1
Разом 1000 сторінок за 11 підходів.
50, 25, 12, 6, 3, 2, 1
Разом 50 сторінок через 7 підходів. А так як у нас 20 довідників, то все
буде 140 підходів. Це більш ніж в 10 разів більше!
Вам потрібні результати реальних тестів?
vinxru, спасибі за розгорнуту відповідь.
Ви маєте рацію, потенційно «Швидкість пошуку впаде в стільки разів, на скільки таблиць ви поділили дані (умовно)».
Але це буде в тому випадку, якщо всі таблиці будуть однакового розміру (ви описуєте раделеніе однієї великої таблиці на 8 маленьких), і якщо шукати ми будемо за індексами. Але на самій-то справі поділ таблиць відбувається не за кількістю записів, а по їх вмісту і відносинам між даними, та й далеко не всі стовпці потрібно індексувати.
Тобто основна таблиця з нерухомістю, хоч з безліччю стовпців, хоч з п'ятьма, буде одного і того ж розміру - n. А ось все, що дублюються дані не потрібно розміщувати в цій же великий таблиці.
Наприклад, у нас є в базі кілька типів будинків:
Чешки (9 поверхів, панельні, з вантажним ліфтом)
Чешки (12 поверхів, панельні, з вантажним ліфтом)
Чешки (9 поверхів, цегляні, з вантажним ліфтом)
Якщо ви розмістите ці дані в основній таблиці, вони, по-перше, займуть 4 шпальти ( «чешка», 9, «цеглина», «так»).
По-друге, щоб швидко шукати по ним, вам треба буде створити додаткові індекси.
Я б зробив по-іншому: створив окрему таблицю «тип будинку», яка б містила б ці типи, і була б дуже маленькою. В основній же таблиці додалася б всього одна колонка - тип будинку.
Чесно кажучи, не можу стверджувати, що пошук в другому варіанті «цегляного дев'ятиповерхового будинку з ліфтом, чешка» буде швидше, ніж в першому (з індексами), але як мінімум ви виграєте на розмірах бази і на зручність роботи з нею.
будь-які додаткові таблиці завжди зменшують швидкість роботи, складаємо все-все в одну.
Згоден. Виправлю на «будь-який додатковий JOIN або запит завжди зменшує швидкість роботи.».
Я поклоняюся Нормальною формою, як і багато тут. Але я давно зрозумів, що є три крайності: Продуктивність, Простота і Нормальна форма, між якими доводиться вибирати.