Сижу вот и втыкаю. Подскажите обладающие изщренным опытом.

Есть сайт, ну или не сайт, а любой другой многопользовательский интерфейс для обращения к базе.
Есть сервер, один на все.
Есть один тип данных в двух наименованиях.

Так вот вопрос. Как быстрее будет работать кухня при одновременном множественном обращении к данным обоих наименований (обращения для просмотра):

1. Если в одной базе SKL организовать одну таблицу для обоих наименований

2. Если в одной базе организовать две таблицы с разными префиксами для каждого наименования.

3. Eсли для каждого наименования создать отдельную базу.

Постановка упрощена до предела, для более однозначных ответов.

Спасибо.

фывфывфывфывф

а вообще - фигня это все. для просмотра пофиг почти

(1)Пару слов в обоснование ? Если  не трудно.

о_О

что такое "база SKL"?

Выборка по индексу будет быстрее, если меньше таблица, то есть, в случае отдельных таблиц или отдельных баз должно быть быстрее, конечно, если вы не используете два разных индекса.
При чтении, же, многопользовательский доступ в одну и ту же базу особенно и не тормозит.

[Есть один тип данных в двух наименованиях] — чО?

(2)Даже на больших массивах ?
(5)SQL. Плохо в школе учился.

(8) Ничо ) Номенклатура, например двух наименований. Ну может некорректно выразился -поправь

(9) Что значит, двух наименований ?
На разных языках что-ли - неужели вы джумлу имеете ?

фигня какая-то. с учётом того, что в любом современном сервере БД ещё и кешируется всё подряд явно или неявно, то практически побарабану

(11) Ну, как бы, кеш не безграничен, а выборка из таблицы часто зависит от количества строк в ней, и две таблицы будут работать быстрее.

(6)>в случае отдельных таблиц или отдельных баз должно быть быстрее

Вот тонкость не совсем понимаю ... Или совсем.

>два разных индекса
Примерно представляю что это, но где они хранятся ? если две базы то разве не два индекса автоматом ?

(10)Не ... Имею я не джумлу. Но речь идет о джумле, но насамом деле пофиг откуда обращаться. Или я неправ ? Ну если только у джумлы какой то сильно особый код запросов.

(11)>сервере БД ещё и кешируется всё подряд явно или неявно

Я правильно понимаю, что единожды запрошенное из разных баз лежит в кеше в одном ?

Ну тогда вариант с 2 базами действительно не актуален. Или вообще проблема высосана из пальца ?

(2)Ну да. Доперло. Если нет блокировок, то почти монопенисуально.

(10) Нет, не разных языков, а просто две разных номенклатуры.

(12)Ага. Логично.

(12) и очень часто приходится делать выборку всех записей в большой таблице? если да, то надо что-то в консер^Wархитектуре поменять

(13) Просто я не зря про джумлу спросил - у неё система кеширования встроенная и второй раз просто в базу вообще не обращаются.
Работа кеша зависит от настроек сервера, но если будет два подключения, то кеша тоже будет два - так быстрее их анализировать.
(17) Что касается перебора всех таблиц, то работа с текстами чаще всего без перебора не обходится - хотя бы при выборе BLOB-полей.
Вопрос в том - нужно ли программе выбирать данные двух видов одновременно - если да, то база однозначно одна, если нет - то лучше две.
То есть одна программа - одна база.
Две программы - две базы.

(18) для работы с текстами в блобах обычно применяются специальные средства, типа "полнотекстового поиска"

(17)Ну сайт с каталогом на 250 наименований и с фильтрами по 4-5 параметрам. До 150 единовременных обращений к каталогу.

Ну есди интерфейс сайта считать программой, то программа одна.

(19) Это понятно, но как ни оптимизируй, а выбирать данные придётся перебором.
В частности, web-сервер из базы выбирает текст страниц по индексу, а данные - уже перебором.
(20) При таких "размерах" не принципиально.
Если 250 тысяч, то уже думать надо.

(21)если 250 000 то пусть думают другие :))

(22) Просто 250 наименований, скажем индекс по 4 байта - так это он в одну страницу памяти влезет без проблем.
Так что точно - одну таблицу.

(23)Ага, суть понятна.

Если это утверждение верно, то впринципе обсуждение можно прекратить.
Если нет иных мнений.

В общем, в (2) правильно ответили.
Я просто как-то считаю, что база - это где не менее полумиллиона записей.

>одну страницу памяти влезет без проблем
Одна страница физической памяти организванная SKL для своих нужд ? Или просто одна страница выделяемая под процесс ?

И ещё, что касается сайта.
Всегда считалось хорошей традицией делать один сайт в одной базе, чтобы было проще переносить сайт с сервера на сервер.
Ту же джумлу без проблем так переносят с одного хостинга на другой.
Использование в одном сайте нескольких баз нецелесообразно, так как будет излишняя необходимость выбора базы перед обращением.
Ну а несколько сайтов в одной базе не позволят их разнести.

(26) Это я примерно прикинул размер индексов - на самом деле их устройство гораздо сложнее, так как долны хранится ещё и ссылки положение записи в базе, а также флаги для межпроцессного использования.

А вообще - за то время - пока мы тут что-то обсуждали, уже можно было базу и сделать.

(28)Ага. Дак я уже понял все.

Спасибо еще раз всем.

Кстати - это не твой "собрат по несчастью" ?
Настройка Apache2

:) Не. Я туду щас какраз свои сокровенные познания пытаюсь выгрузить.

(20) при 250 строках в таблице MySQL время чтения будет пренебрежительно малым относительно общего времени выполнения кода. так что пофигу как организовать.

не так давно тестировал новый движок своего сайта под нагрузкой. в базе 50К товарных позиций + порядка 4000 категорий, что примерно в 5 раз больше, чем в реальности. так вот даже при таких раскладах временем чтения из базы можно смело пренебречь.

вот например:
Запрос открыт за 0,197c [0,196c выполнение, 0,001c выборка]

Это выполнение запроса с условием LIKE на таблице 50К строк. Выборка за 1 мс и то подозреваю только потому, что меньшие интервалы прога не замеряет.

(32)Да, уже объяснили.
Твой пример вообще очень наглядный и я уже не заморачиваюсь по этому поводу.