Форум MySQL

Столкнулся с такой задачей. Есть проекты и каждый проект относится к определенному типу проектов (видов). Каждый вид проекта определяет разные типы и виды данных.
Поэтому при проектировании БД я вижу такой нормальный подход. Таблица проекты - ид|имя_проекта и собстенно для каждого такого проекта отдельная таблица с характерными для него типами.
Проблема в том что видов проектов много, всего 140 - не больше не меньше. Это по природе так. Поэтому получается придется только для видов проекта заводить 140 таблиц. Для MySQL такой объем таблиц нормальная ситуация? Trianon, Valick что скажите?

Число таблиц должно определяться числом сущностей модели.
Но никак не числом экземпляров объекта.
А значит у Вас будет одна (две , три, но не десять и не 140) таблица проектов
одна (...) таблица видов проектов.
одна (...) таблица типов проектов (если вид и тип - разные вещи.)
Возможно одна (две, три) связующие таблицы.

похоже, он имеет в виду, что проекты принципиально разные и должны иметь разные поля и, таким образом, различную структуру таблиц. Если разница не слишком велика, таблицы можно объеденить в одну. А если одинаковые по смыслу поля должны иметь разные типы данных, можно назыать их field_type1, field_type2 (где field - это, например "name") и, таким образом, они не будут друг другу мешать. Но если объединить таблицы кажется неразумным (к примеру, полей и записей получается очень много и они будут медленно обрабатываться), то 140 таблиц в базе - это не страшно.

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

принципиально разные проекты не проектируются в рамках одной модели. И (числом 140) не разделяют одну БД.
И задача, как я понял, не в проектировании самих проектов, а в проектировании схемы управления ими.

Я уже намикал Адмиралу, что излагаться нужно яснее

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

Если еще проще понять мою мысль, то еще пример.
Есть клиника, у нее есть пациенты и есть анализы, которые сдают пациенты. Анализов куча (анализ крови, биохим. анализ, гормоны щитовидной железы итд) но все эти анализы заранее известны и известно какими свойствами они обладают. И больше видов анализов никогда не станет, потому что этой выйдет за рамки предметной области тогда. Поэтому я пошел таким методом создать для каждого анализа свою таблицу. Аналогично в данной ситуации с проектами.

Я бы предпочел еще такой вариант это создать таблицу тип проекта - ид|имя| и таблицу свойства/характеристики проекта - ид_характеристики| имя_свойства
и соответственно таблицу куда вносятся исследования для конкретного субъекта для кого делается проект где сделать такие поля ид_исследования, ключ для таблицы с названиями проектов,ключ для таблицы названием характеристики, значение.

Минусы следующие - на генерацию отчетов потребуется более сложные запросы и объем данных в таблице будет быстрее увеличиваться за счет того что для

> To Trianon (13.01.2010 в 03:06)
>Что Вы понимаете под тем как я выразил мысль по поводу проекта?

Я по этому вопросу ни слова не сказал.

все-таки послушаю Вас и буду думать над проектированием 2,3 связующих таблиц
upd Trianon, скажите а вообще есть ограничение в БД по кол-ву создаваемых таблиц в одной БД?

upd Просто у меня на хостинге ограниченное число БД, приходится префиксы добавлять

upd1. http://dev.mysql.com/doc/refman/5.0/en/limits-windows.html
upd2. Число хостингов-то у Вас неограничено?

Мне хосетр на площадку дает 5 бд, и 10 доменов, если использовать больше приходится доплачивать. Ну вот приходится а одну БД минимум 2 проекта прикручивать, бывает и больше. Но там сайты не столь ресурсоемкие.
Давайте теперь по поводу ограничений в Windows разберем. С английским туго, переводио машиной

1.Число открытых дескрипторов файла на Windows ограничено максимумом 2048, который, возможно, ограничивает способность открыть большой ряд столов одновременно. Этот предел есть благодаря функциям совместимости использовал, чтобы открыть файлы на Windows, это использует POSIX слой совместимости.

Это ограничение также вызовет проблемы, если вы пробуете установить open_files_limit к значению, больше, чем 2048 предела файла.

Ничего тут не понял. Объясните Вы пожалуйста.

На 32-разрядных платформах Windows не возможно использовать более чем 2GB оперативной ПАМЯТИ в пределах единственного процесса, в том числе MYSQL. Это, потому что ограничение физического адреса на 32-кусок Windows - 4GB и значение, устанавливаемые по умолчанию, в пределах Windows - раздробить виртуальное адресное пространство между ядром (2GB) и пользователем/приложениями (2GB)
Иными словами MySQL максимум может задействовать до 2 Гб, даже если оперативной памяти на 4 гб?

По остальному ясно

>Ничего тут не понял. Объясните Вы пожалуйста.

там написано, что больше 2048 файлов в windows одновременно открыть не удастся.

1 таблица MyISAM - 3 файла (формат, данные, индексы)

А если MySQL - сервер располагается на линуксе, то я так понял это ограничение действует только на виндовс системах.

А если к таблице обратилось одновременно больше одного клиентских запросв, тот они идут в очередь? Извиняюсь, конечно, я тут могу глупость сказать, но мне интересно от Вас услышать

>Извиняюсь, конечно, я тут могу глупость сказать, но мне интересно от Вас услышать

Вот этого Вы как раз почему то не делаете, не смотря на интерес.

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

Ну а если Вы хотите узнать, что я думаю об ограничениях, то пожалуйста.
Ничего не думаю.
Мне эта тема неинтересна, т.к. я не могу представить собственный проект, который бы уперся в количественные ограничения MySQL.

у Вас в таблицах с анализами были повторяющиеся поля? Вообше если честно я в отпуске и на некоторое время очистил свой мозг от PHP и MySQL :) Тусуюсь тут в режиме "только для чтения"))

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