Доброго времени суток всем!
Есть такой вопрос:
Как сказывается на быстродействии то, что я стараюсь делать как можно меньше таблиц? Например: есть таблицы T1, T2, T3. Отношения между ними: T1#T2=M:M, T1#T3=M:M. То есть нужны еще две таблицы связей. Что лучше с точки зрения производительности: две таблицы связей или лучше иметь одну, но с флажком: в ней будет одно поле для id первой T1, затем еще одно поле - id записи одной из двух других и еще флажок, значение в котором будет показывать, какой же именно из вторых таблиц записано в таблице связей второе id?

То есть я так понял, что серверу значительно быстрее работать с одной таблицей связей и флажком, чем с десятком разных, но без флажка?!

INSERT и SELECT таблиц будет делаться на несколько порядков больше, чем UPDATE. Работа с таблицами связей, если их двое - разница невелика, меньше, чем на порядок.

MelaniПростите. а как вы собираетесь заносить данные в таблицу связей + помечать нужные флажком?? это у вас получится??

Улыбайтесь чаще, людей это раздражает.

Получится, это ведь несложно, в таблице будут строки:
id1-id-T2 {T1.id1-T2.id} - id1 - из первой таблицы, id - из второй
id1-id-T3 {T1.id1-T3.id} - id1 - из первой таблицы, id - из третьей
id1-id-T3 {T1.id1-T3.id} - id1 - из первой таблицы, id - из третьей
id1-id-T3 {T1.id1-T3.id} - id1 - из первой таблицы, id - из третьей
id1-id-T2 {T1.id1-T2.id} - id1 - из первой таблицы, id - из второй
Третье поле - это флажок, показывающий, какой таблице принадлежит id2: либо T2, либо T3

Но наверное я действительно в какую-то ерунду здесь полез...
P.S. я вспомнил, почему задал этот вопрос - я где-то на форуме давно читал, что использование INNER JOIN для связки таблиц, вместо WHERE t1.id=t2.id замедляет выполнение запроса минимум в два раза. Меня это тогда поразило, так как считал, что это одно и то же.

Melaniнасколько я помню INNER в операторе Join указывает, что надо выбирать неповторяющиеся записи.
Неповторяющиеся - это DISTINCT
А INNER JOIN, как написано в справочниках, осуществляет полное объединение таблиц.

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

Улыбайтесь чаще, людей это раздражает.

Понятно... Спасибо.
Буду разбирать тщательно собранные таблицы с флажками обратно))

Melaniвот тебе и ответ - 2 разные кучи шмоток. одна твоя, другая твоей супруги. а живёте в одной комнате. ))) пример более, чем наглядный.

Улыбайтесь чаще, людей это раздражает.

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

softwarer AXAEА кроме того - люди ведь не индексируют свои вещи))
Ошибаешься. Вещи в куче как раз хорошо проиндексированы, в небольшой куче эффективность как у хэш-индекса (увидел нужную - взял).

Это в маленькой, а у меня куча большая. Там выше пост, про то, что общая куча эффективна, пока она маленькая. А если куча большая - даже человек в сотне вещей будет перебирать практически все вещи по порядку, прежде чем найдет нужное - вот и нету индекса. Он ведь в куче не выбирает сначала все носки, потом все красные, потом левый. Он вроде схватит более или менее похожие носки, потом просмотрит их поочередно)) А вообще должен признаться, не знаю, как работают индексы. Нам показывали, как каким-то хитрым образом идет за четыре шага выборка одной записи из ста тысяч, но я пока не понял, как так получается((

chronПоднятая тема не нова, но не мог бы автор озвучить предметную область ? Кажется, недавно я слушал подобный разговор.

Предметная область - одна флажечная таблица или лучше несколько отдельных таблиц

Ginas AXAE chronПоднятая тема не нова, но не мог бы автор озвучить предметную область ? Кажется, недавно я слушал подобный разговор.

Предметная область - одна флажечная таблица или лучше несколько отдельных таблиц

Под предметной областью имеют в виду прикладную задачу. Например: учет вещей в комнате (зверей в зоопарке/товара на складе).

У меня учет карт профосмотров... Карты пациентов, обследования на ней, атрибуты карты, атрибуты обследования, варианты заполнения атрибутов...((
Атрибуты карты и атрибуты обследования на карте, а так же варианты заполнения их - переплетаются. Я назвал сейчас две и еще две сущности - поэтому связок будет четыре... Поэтому разобью свою одну таблицу связок на четыре таблицы...

softwarer AXAEА если куча большая - даже человек в сотне вещей будет перебирать практически все вещи по порядку,
Да ладно тебе. Он просто развалит ее по принципу половина-направо, половина-налево и снова увидит нужное :)

Но именно поэтому начиная с определенного размера кучи человек раскладывает ее по полкам в шкафу (читай - по большему количеству тех же куч). Для малоселективных критериев (а твой флаг - из таких) партиционирование - один из вариантов эффективного выбора.

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

Да понятно... Но раз уж я взялся - работать надо(( Я делал "как естественней" - я запутался... Таблицы появляются как грибы по мере того, как появляются все новые и новые условия задачи.((
Просто здесь на предприятии никто до конца не может объяснить, что собственно надо от базы данных (причем упоминается, что сейчас одно, а завтра может быть другое), поэтому я трепыхаюсь с ее структурой... Я видел где-то здесь на форумах мысль, что таблицы с динамически изменяемым набором атрибутов не нужны, что если появляются такие мысли - предметная область не до конца определена. Я согласен с этим - если полностью определенная предметная область, то проблемы вряд ли могут быть - но считаю так: к сожалению то, что если предметная область до конца не определена - это не является уважительной причиной отказа от разработки... ((

Требований было меньше и все казалось простым. И я действительно один работаю... Но политики предприятия наверное здесь не стоит касаться, а то если так все рассудить - я должен буду остаться без работы.((

Есть такая глобальная проблема, которая меня все чаще беспокоит: код пишется практически один и тот же, разница только в паре строк. Например поиск по одному полю и поиск по другому полю - вроде один и тот же алгоритм, код будет похожим, но с парой измененных строк. Ладно если эти мне удастся "объединить", а если допустим в условии еще и добавится "за исключением тех, где в таком-то поле есть..." - это же еще умотаться кода будет - а алгоритм не изменится. Копируешь код, добавляешь пару строк и вот все работает.. А если так много раз сделать - запутаться запросто... Да и неприятно - один и тот же код копируешь и меняешь, добавляешь пару строк...((

А отдельная проблема на отдельном уровне и десятки тысяч таблиц... Тут дурацкая закономерность: девять к одному. Это означает, что девяносто процентов однородной информации обрабатывается одним способом, а десять - другим (это в смысле вдобавок(!!!), а не взамен, к способу обработки тех 90 процентов), и в других местах учитываются. Причем эти десять в свою очередь могут еще распадаться на 9:1 и причудливо переплетаться с вышестоящими уровнями... ((( Ну самый простой пример - очень не хочется делать таблицы с однородной информацией, где лишь в десяти строках из ста заполнено какое-то поле только потому, что эти десять строк нужно обрабатывать еще и по-другому...

P.S. Выговорился... Я просто уже четыре дня не могу вообразить удовлетворяющую меня структуру базы из двух десятков таблиц. База данных с тридцатью уже есть, которая делает то же самое - но ей так неудобно управлять, изменять, модифицировать... Потому что там просто не предусматривал я этого.

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

OraDen AXAE softwarer AXAEА если куча большая - даже человек в сотне вещей будет перебирать практически все вещи по порядку,
Да ладно тебе. Он просто развалит ее по принципу половина-направо, половина-налево и снова увидит нужное :)

Но именно поэтому начиная с определенного размера кучи человек раскладывает ее по полкам в шкафу (читай - по большему количеству тех же куч). Для малоселективных критериев (а твой флаг - из таких) партиционирование - один из вариантов эффективного выбора.

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

Да понятно... Но раз уж я взялся - работать надо(( Я делал "как естественней" - я запутался... Таблицы появляются как грибы по мере того, как появляются все новые и новые условия задачи.((
Просто здесь на предприятии никто до конца не может объяснить, что собственно надо от базы данных (причем упоминается, что сейчас одно, а завтра может быть другое), поэтому я трепыхаюсь с ее структурой... Я видел где-то здесь на форумах мысль, что таблицы с динамически изменяемым набором атрибутов не нужны, что если появляются такие мысли - предметная область не до конца определена. Я согласен с этим - если полностью определенная предметная область, то проблемы вряд ли могут быть - но считаю так: к сожалению то, что если предметная область до конца не определена - это не является уважительной причиной отказа от разработки... ((
В такой ситуации поможет только бюрократия :), все требования к системе только в письменном виде как минимум с подписью специалиста из предметной области и его начальника, никчему
брать на себя ответственность за предметную область. А насчет "(причем упоминается, что сейчас одно, а завтра может быть другое)" заказчик должен четко понимать что система
пишется под конкретную задачу с конкретными требованиями, если требования не определены
четко то SAP им в помощь :-)

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

аверное тоже стать придется бюрократом: эта система разрабатывалась как раз под такой бюрократией - три года... Пока я маленький штатный единственный программист и меня раздражают подписи - для меня лишь бы работала система... Да НИКТО(!!!) там ни в жизнь не сможет написать, что им собственно нужно и никто не будет разбираться еще минимум года два в этом. У меня нет начальника. Я сам по себе там - типа героя-одиночки. Я новичок в базах данных. Меня не интересуют деньги, меня не интересует правильность их требований - для меня лишь бы эта система работала так, чтобы удовлетворить их требования и чтобы люди имели к ней минимальное отношение в управлении ею. Пока мне нравится разработка и платят достаточные для меня деньги (а мне очень немного нужно...) - я буду заниматься этим, естественно безрезультатно... (((

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

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

У меня код только в программе, хотя сервер MySQL (да, это сервер MySQL, который я использую в качестве промышленного, а не WEB-сервера. Потому что MySQL самая простая) я стараюсь нагрузить как можно больше: если бы не надо было форматировать документ, то я бы в SQL запрос затолкал бы вообще все отчеты полностью с простейшим форматированием - возвраты каретки, табуляции и пр...
Я неопытный новичок, для меня и CodeSmith и ORM - уже что-то нереальное((

гм...очень интересное, интригующее, причудливое изложение ... если чесно - ничо не понял :( раскройте тему поподробнее ?

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