Что лучше, много небольших таблиц в БД или одна, но огромная?

нормализация

ps: короче читай литературу, слишком общий вопрос

Это не ответ специалиста

комменты

в куче маленьких к каждому топику

Это слишком упорин. Одна сущность — одна таблица.

какую именно?

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

Должно хватить приведения к нормальной форме Бойса-Кодда https://en.wikipedia.org/wiki/Boyce-Codd_normal_form

А вычитка потом? Я так понимаю, что выбирать комменты из большей таблицы, скажем для топика, дороже нежели создать для топика отдельную таблицу. Да, таблиц будет 100500! и вот мне интересен в том числе и этот факт - влияет ли количество таблиц на работу сервера?

В общем случае лучше одна большая таблица. С индексом по id топика в твоем случае.
В противном случае есть перспектива напороться на ограничение количества таблиц в СУБД. (Про постгрес не скажу - не знаю сколько в нем объектов можно создавать).
Другой вопрос - сколько потом в этой таблице будет записей.

не мучайся хернёй, тесты прогони

100500 таблиц может и не быть, тебя могут остановить на 65535 таблице. :)

Я представляю как прогнать тестами БД, но кустарными. Поделитесь опытом тестирования?

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

Как лучше хранить комменты, например.

Рано или поздно придется фрагментировать таблицу. Причин тут сразу несколько:

• нагрузка на БД (кол-во запросов, посторонние запросы и т.п.). Один инстанс (процесс, сервер, диски) может не потянуть нагрузку.
• лимиты самой БД на объем таблицы
• блокировки таблицы

Последний пункт во многих случаях решает, когда надо «почковать» таблицу. Когда все компактно и нагрузки никакой нет: проектируй как умеешь, но с мыслями о будущем развитии. Только шибко не забегай вперед :) В процессе развития продукта (или что там у тебя?) ты сам поймешь как удобней, проще, дешевле.

Вот я и пытаюсь спроектировать с запасом, скажем так) может есть какая общая литература на эту тему?

Да литературы-то полно, бери книги по проектированию СУБД. Только нигде тебе не скажут и не напишут, что делать и как в твоем случае. Вобщем случае тебе подойдет одна таблица, но кто знает сколько у тебя других таблиц, какие между ними взаимосвязи, насколько хорошо проведена оптимизация запросов, профилирование, какие объемы, на каком железе все крутится. Думаешь я или кто-то в силах прочитать твои мысли, код и дать 100% удачный ответ? Или в книгах надеешься все написано, т.е. люди только и занимались тестированием 100500 конфигураций, 100500 техник и методик? :)

Не думаю, что вы или кто-то сможет прочитать мои мысли)) Я же спрашиваю в общем. Мне нужна книга в которой описаны принципы работы сервера СУБД, чтоб я понял как лучше мне сделать то, что я хочу. Или, другими словами, от каких параметров отталкиваться в проектировании.

Вот я и пытаюсь спроектировать с запасом, скажем так) может есть какая общая литература на эту тему?

<br/><br/> Для твоей задачи тебе потребуется проприетарное решение. Там всё это есть из коробки, и читать ничего не надо, а в случае затруднений на выручку всегда готовы прийти материально мотивированные специалисты из техподдержки, которые подскажут оптимальный вариант решения конкретной проблемы, а не будут тебе завуалированно намекать на твою альтернативную одарённость, чем зачастую грешат всякие бесплатные советчики в Интернете.

Не думаю, что вы или кто-то сможет прочитать мои мысли)) Я же спрашиваю в общем. Мне нужна книга в которой описаны принципы работы сервера СУБД, чтоб я понял как лучше мне сделать то, что я хочу. Или, другими словами, от каких параметров отталкиваться в проектировании.

А что происходит когда ты свою просьбу «Мне нужна книга в которой описаны принципы работы сервера СУБД» забиваешь не в ЛОР, а в поле ввода гугла, например?

Делать хитрые выборки из больших таблиц помогают индексы.
Рост количества таблиц на производительность сервера, естественно, влияет. Как влияет и наличие сверхбольших таблиц. Нужно искать серединку.

Попробуй обе крайности на твоей конфигурации и сам сравни.

Например, какое решение?

Это я знаю, но меня интересуют предельные значения и что будет в данном случае и как этого не допустить...

Например, какое решение?

То, которое решит конкретную проблему.

Видишь ли, СУБД разрабатывают с прицелом на то, чтобы они обеспечивали оптимальную производительность на типовых задачах. Т.е. ты делаешь стандартную базу по учебнику - и СУБД обеспечивает тебе её работу прямо из коробки. Если же у тебя что-то начинает тормозить или тебе хочется чего-то особенного - значит у тебя какой-то собенный случай и, соответственно, с ним надо разбираться особенно. Т.е. начать с того, что ознакомиться в деталях твоего конкретного юзкейса и текущей, проблемной, реализации (если она есть). Если всего этого нет - то и разговор получается ни о чём. Так вот разница в том, что в коммерческих компаниях платят зарплату людям за то, что они терпеливо байт по байту выдавливают из клиента детальное описание его проекта чтобы можно было проанализировать его специфику и что-то там посоветовать, а бесплатные советчики в интернетах при виде сабжевой постановки задачи тебя просто считают timewaster'ом и диванным теоретиком, советовать которому всё равно нет смысла.

Очень много зависит от конкретной задачи
К примеру однажды приходилось использовать партицирование, т.к. при достижение размера таблицы за 40 гиг, становится трудно с ней работать, но опять же это не всегда реально применять.
http://dev.mysql.com/doc/refman/5.1/en/partitioning.html

Итак, ваша задача состоит в двух вещах: теории и практики. Теория это литература, вроде такой, в большинстве своем там описано как хочется работать с БД. В 95% случаев все, что в таких книгах описано отлично работает и то, что рассказывается, пытаются научить в принципе верно.

Практическая литература это документация к конкретной БД, например, postgresql. Кроме всего прочего это могут быть доп. курсы, скажем, от Oracle, где описываются именно типовые проблемы в рамках эксплуатации БД. По большей части эти знания нужны сис. админам/DBA, а не проектировщику.

Как я вижу, вы сразу пытаетесь продумать все, преждевременно оптимизировать еще несуществующее. Во-первых, все предусмотреть невозможно. Во-вторых, преждевременная оптимизация несет больше вреда, чем пользы.

Еще раз хочу сказать, что вам следует начать с изучения теории, применить полученные знания и постепенно углубляться в технические ньюансы (к ним же относится вопрос оптимизации и того какую архитектуру таблиц выбирать). Можно сразу прочитать про тех. ограничения своей БД, если вы действительно планируете достигнуть ее лимитов. Достигнуть же лимитов БД можно только при специфичных задачах (ваша судя по задаче хранить комментарии к ним не относится). В большинстве случаев проблема возникает на середине пути, когда работает куча разных элементов (таблицы, действия вставки/выборки, создание временных таблиц и т.п.), что в совокупности приводит к тормозам всего приложения (БД тормозит же из-за такого «мощного» приложения). И сколько все не планируй, сколько не пытайся обойти все ньюансы, в один прекрасный день возникнет новая, специфичная только для ваших условий проблема, которую придется решать новым, неоткрытым и неизученным способом.

хранить комменты в куче маленьких к каждому топику и плодить их с появлением новых топиков

офигенная трава. адресом дилера не поделишься?

Однозначно одну таблицу и потом по необходимости её шардировать по любому ключу, по топику например. Будет проще управлять таблицей (всё в одной таблице) и не страдает производительность(разделов много с маленькой частью данных)

По обстоятельствам.

Еще проект не написал а уже расчитываешь на сто миллионов комментов?

По большей части эти знания нужны сис. админам/DBA, а не проектировщику.

Если проектировщик знает меньше чем ДБА, то _очень_ мягко говоря он гавно, а не проектировщик.

Если проектировщик знает меньше чем ДБА, то _очень_ мягко говоря он гавно, а не проектировщик.

Значит все проектировщики - говно :)

Мда... Некоторые, даже используя СУБД, продолжают писать «на файлах»

Внезапно, есть люди, работающие в индустрии over 10,20,30,... лет, а не только студенты. Если с нормальными специалистами работать не доводилось, то все впереди, если повезет. Нормально спроектировать (так чтобы в проде потом не огребать проблем, при расширении системы, дописывании нового функционала, или изменении логики при изменении в законодательстве и выходе новых версий ПО) может только человек, который пишет код приложения, sql, админит сервер/ферму субд (т.е. знает подводные камни всего стэка) и постоянно использует продукт и сидит рядом с людьми, которые его используют и понимает бизнес-процессы (т.е. предметную область).
На получение всех этих знаний нужны годы, в течении которых на собственных ошибках понимаешь, что полагаться всегда можно только на самый базовый функционал любых используемых систем, а нормализация - палка, минимум, о трех концах. В результате, такие проекты легко переживают смену и добавление платформ.
Собственно поэтому, раньше, когда такие люди работали на предприятии и писали под него софт, они выжимали из 100МГЦ такую же производительность приложений, как нынешняя молодежь из многоядерных ГГЦ.

Внезапно, есть люди, работающие в индустрии over 10,20,30,... лет

В жопу старпёров! Я бы предложила ввести закон, запрещающий людям заниматься заниматься программированием (как и проектированием сруктуры БД) по достижении возраста в 30 лет. Дожил до 30ти лет - всё, переходи на тренерскую работу: администратором системы, манагером или проектируй приложения на более высоком уровне. От этих престарелых коней с ихними Perl'ами, TeX-ами, представлением о том, что UI должен обязательно выглядеть как говно мамонта и тормозить и прочей ископаемой тупизной - от них сплошной вред на производстве.

раньше, когда такие люди работали на предприятии и писали под него софт, они выжимали из 100МГЦ такую же производительность приложений, как нынешняя молодежь из многоядерных ГГЦ.

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

Дорогая С, положи, пожалуйста, чушь на место. Я не собираюсь доказывать очевидное и обсуждать домыслы про уй.

Хотя, конечно, такие запатентованные изобретения молодых юзабелистов, как шпингалет на яфоне (у меня на даче такой в сортире, прикинь, только NG - с 3d и тактильной обраткой), тыканье пальцем и увеличение картинки при растягивании (ухты прямо как на воздушном шарике) заставляют грустно улыбнуться.

Вообще-то все зависит от того, что это будет за система - в большенстве случаев люди в таких случаях обходятся одной таблицей для хранения комментов. Учтите, что при большом количестве таблиц в системе растет и объем словаря СУБД, а это тоже расходы ресурсов. Короче, надо понимать чего вы хотите от системы и какая нагрузка на систему планируется.

В контексте вышесказанного - как тут, на LOR'е устроены комменты?

Вангую, что одна таблица. Не делает никто по другому. :)

Дорогая С, положи, пожалуйста, чушь на место. Я не собираюсь доказывать очевидное

Ха-ха-ха, нуконечно же «очевидное»! Первый признак ЛОР-овского (да и не только) тролля - это неаргументированные высказывания со ссылками типа «как всем известно», «всем очевидно что»

и обсуждать домыслы про уй.

У тебя случились домыслы про уй? Большое спасибо, что ты не обсуждаешь их со мной!

Мужука тебе надо, раз ui с чем-то другим ассоциируется.

Мужука тебе надо, раз ui с чем-то другим ассоциируется.

Вовсе нет, я UI как раз правильно пишу, а у тебя вот опечаточки по фрейду. Видимо, очень уж тебя заботит этот вопрос.

Короче, конкретики по теме обсуждения мы от тебя не дождёмся, правильно я тебя понимаю?

Я решил создать ветку комментов для каждой комментируемой сущности. Постараюсь протестировать. Если получится, покажу результаты. К стати, какие результаты тестирования важны для БД?

какие результаты тестирования важны для БД?

Для БД не важны никакие результаты тестирования. Бд - это неодушевлённая сущность и поэтому ей пофиг на всё, в том числе и на то, какие ты там получил результаты тестирования. А для тебя самого какие результаты тестирования БД важны?

Одна таблица - однозначно. Если у тебя будет столько комментов, что одна таблица станет проблемой - у тебя будут ресурсы на решение этой проблемы. Но изначально ты должен спроектировать приложение так, чтобы то, как ты хранишь комменты никак на него не влияло. Т.е. ни один функциональный блок не должен у тебя взаимодействовать с базой. В идеале должен быть один класс, в одном единственном файле, предоставляющий API к твоим данным. И когда тебе придется что-то изменять ты сможешь заменить только этот файл. По большому счету - нет никакого смысла вообще размышлять над тем как хранить данные. Забудь ты про свою БД - думай только об API.

А поскольку база данных как раз и представляет собой «одни данные» в процессе нормализации, разбитые на несколько таблиц, то вся бизнес-логика должна быть представлена одни классом, в единственном файле, представляющим API к этим данным...

Не согласен. Логика должна быть отделена от БД соответствующим API. Ты должен быть полностью свободен в выборе базы. Завтра тебе захочется заменить мускул на постгрес и чо? Переписывать всю логику? А так ты только сменишь «драйвер БД». Или как задачу у ТС. Завтра тебе не будет хватать одной таблицы для хранения комментов. Что будешь делать?

Завтра тебе захочется заменить мускул на постгрес и чо? Переписывать всю логику? А так ты только сменишь «драйвер БД».

Тогда для чего тебе менять твою БД? Да, MySQL откровенное говно, которое не подходит для сколько-нибудь серьёзных приложений поскольку не в состоянии оптимизировать исполнение запросов с JOIN-ами. Да, те кто вынужден работать с MySQL вынуждены извращаться, вытаскивать данные в приложение, и вручную уже их там связывать, получается всё равно медленно, чем один сложный запрос в тот же постгрес, много кода, значительно повышается вероятность ошибок, значительно повышаются требования к ресурсам на клиенте (память и CPU). Ну выкручиваются.

Хорошо, есть Постгрес, который значительно лучше справляется с этой задачей, работать с ним проще и эффективнее - ведь данные на сервере кешируются и используются для обработки запросов множества клиентов.

Но вот что ты получишь просто перейдя на Постгрес, на уровне смены «драйвера БД» без изменения логики приложения? Ну да, он не хуже будет обрабатывать простые запросы, производительность исполнения которых зависит разве что от производительности диска. Но и не сильно лучше. Чтобы получить доступ к плюшкам другой БД - ты должен переписать приложение так, чтобы оно эти плюшки использовало. А иначе получится замена шила на мыло.

Но и не сильно лучше. Чтобы получить доступ к плюшкам другой БД - ты должен переписать приложение так, чтобы оно эти плюшки использовало.

Ты видишь API БД-ориентированным поэтому и приходишь к таким заключениям. БД-ориентированное API действительно глупость и все будет как ты описал. API должно быть ориентированно на приложение. Т.е. оно должно предоставлять данные которые нужны приложению в том виде в котором они ему нужны. Если есть какая-то предобработка - она должна выполняться именно в этом API, но это не значит, что это API должно хэшировать пароль например при записи в базу - его задача только запись, а хэш должен считаться уже приложением. И вот тогда ты сможешь извлекать выгоду из смены БД. Тем более что для сложного приложения скорее всего и постргреса не хватит - рано или поздно тебе понадобится симбиоз реляционки и NoSQL и даже такая замена не должна приводить к чему-то такому, что заставит переписывать приложение. А если всю логику твоего приложения можно построить исключительно на запросах к БД - то это выглядит несколько странным.

Так у тебя приложение и есть API. Кто там дёргает это API - юзер через GUI или другое приложение-API это дело десятое. За твоим API сразу начинается работа с данными. Ты добавляешь в API некоторый метод, например CreateCustomer и оно должно полезть в данные проверить не был ли этот кастомер уже случайно создан, накинуть поинтов реферреру, который этого кастомера привёл, проверить нет ли каких-либо бонусов новым кастомерам, пришедшим в этот период и т.д. и т.п.

Оно может лезть за данными через некий абстрактный драйвер БД, который представляет подмножество плюшек, общее для всех поддерживаемых баз данных либо использовать специфические возможности конкретной СУБД (в т.ч. и NoSQL), либо использовать разную логику для работы с разными БД, что его неоправданно усложнит и сделает чрезвычайно дорогим в поддержке (при миллионных тиражах последнее возможно и окупилось бы, но что-то я не видел таких приложений с такими тиражами).

лучше каждый коммент в отдельной таблице