MySQL сложный поиск в группах с ИЛИ

[pokerface]

есть такое условие у банка, который требует документы от клиента, ему нужна 2-ндфл ИЛИ трудовая
при поиске неизвестно, чего хочет банк, банков много, просто нет трудовой у клиента например (tk=0), как выкинуть банк, который её требует в пакете условий?
как его сохранить вообще в базе правильно и потом найти?
условия могут быть такими:
1. пакет документов.
2. пакет + один из нескольких + еще один из нескольких.
3. пакет + (один ПАКЕТ ИЛИ второй ПАКЕТ ИЛИ третий пакет)

если делать через отдельную таблицу, куда складывать условия-пакеты, то примерно как-то так:
bank='bank1',packet='packet1',doc1='ndfl',doc2='tk ',doc3='td' (это ИЛИ)
bank='bank1',packet='packet2',doc1='pass'
bank='bank1',packet='packet3',doc1='inn'

но тогда, если у клиента нет tk, то where doc1 != 'tk' AND doc2 != 'tk' AND doc3 != 'tk'
а потом ещё раз проверять (для каждого банка), чтобы у этого банка _во всех_ пакетах не было тк
а ещё для каждого документа так делать надо
топорно, мягко говоря..

[pokerface]

Сообщение от x999xx

select * from banks where ( (passport=1) and (2ndfl=1) and ( (Загран=1) or (ВУ=1) or (1=ИНН) or (1=СНИЛС) or (1=ОМС) ) and [третий док также] ) limit 1000500

ты опять ищешь банк от имени клиента, а условие ставишь от имени банка
я должен знать об этом условии, чтобы так написать where or and, а там 50 банков и у каждого свои условия

[x999xx]

блять! я наверное тупой
извини я еще раз подумаю

банк...клиент... 1С от buka entertainment какойта

[chesser]

Сообщение от pokerface

а ты мне воду льёшь

это не вода, а основы работы с БД. Именно в них у тебя проблемы, имхо

Сообщение от pokerface

это НФ1

в моем примере? как?

ну извини тогда, пойду повторю материалы лекций по теории БД, которые я читал своим воспитанникам

[x999xx]

Сообщение от chesser

это не вода, а основы работы с БД. Именно в них у тебя проблемы, имхо



в моем примере? как?

ну извини тогда, пойду повторю материалы лекций по теории БД, которые я читал своим воспитанникам

не, не, ты посмотри что мне ответили

ты расписал схему простешего поиска по одному документу есть/нет
он кстати делается в 1 таблицу так то )

ебать такое гуру еще говорит что и как делается но мне одному кажется, что чего-то для понимания не хватает в его словах?

это как решать уровнение с неизвестной переменной и придти к выводу что неизвестная переменная это х
бред какойто

[chesser]

Сообщение от chesser

если делать БКНФ, то будут следующие таблицы справочников:

bank (id, name)
package (id, name)
doc (id, name)

и таблицы связей:
package_doc (id, package_id, doc_id)
bank_package (id, bank_id, package_doc_id)

отличие БКНФ от 3НФ, в том что по 3НФ вместо последних 2-ух таблиц будет одна relations(id, bank_id, package_id, doc_id), при этом оба варианта являются правильными и выбор зависит от цели оптимизации.

Сообщение от pokerface

это НФ1

на основе чего ты сделал вывод о том, что это НФ1? Обоснуй, пожалуйста.

[pokerface]

Сообщение от chesser

на основе чего ты сделал вывод о том, что это НФ1? Обоснуй, пожалуйста.

вот это:

Сообщение от chesser

и таблицы связей:
package_doc (id, package_id, doc_id)
bank_package (id, bank_id, package_doc_id)

1:1 = 1НФ
она кстати без id идёт, как и все формы

а это:

Сообщение от chesser

bank_id, package_id, doc_id

2НФ

в принципе то наверное можно и так записать мой вариант:

table packets:
bank packet pass ndfl zagran vu inn snils oms sts zagranT dms tk
sber     1          1      0         0     0  0    0    0   0     0     0   0
sber     2          0      1         0     0  0    0    0   0     0     0   0
sber     3          0      0         1     1  1    1    1   0     0     0   0
sber     4          0      0         0     0  0    0    0   4     12    1   1

но в моём варианте пакет документов с ИЛИ в одной строке и нужно просто найти 1 совпадение на всю строку
а в твоём чё делать? придётся where packets "из одной лодки" как-то указывать

[chesser]

Сообщение от pokerface

1:1 = 1НФ
она кстати без id идёт, как и все формы

а это:
2НФ

нет, ты не прав и неправильно понимаешь смысл нормализации БД.

Во-первых, ты почему-то разделил мой вариант нормализации на 2 части - зачем? Именно эти 5(4) таблиц вместе являются приведением области данных к БКНФ (3НФ). Их нельзя рассматривать отдельно, т.к. нормализуется именно (предметная) область данных целиком.

Во-вторых, я тоже могу молча кидаться ссылками на википедию: 3НФ, БКНФ.

В-третьих, могу и не молча в моем примере я представил предметную область в виде отношений кортежей данных, каждое из которых состоит из ключей и неключей, при этом неключевые атрибуты являются информацией о ключе (внешнем).
Информация о ключе - это ID. При приведении в 3НФ/БКНФ в отношениях(таблицах) остаются только ключевые элементы и ID внешних ключей. Разницу 3НФ и БКНФ объяснять не вижу смысла, т.к. в данном контексте она не существенна.

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

Сообщение от pokerface

она кстати без id идёт, как и все формы

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

Сообщение от chesser

Чем меньше НФ, тем проще "на вид" запросы, работают они быстрее при достаточном количестве памяти, хранение данных дороже и наоборот: чем выше НФ, тем памяти требется меньше, структура запросов сложнее, работает медленнее, хранение данных дешевле.

на счет сложности запросов еще хочу добавить следующее: чем меньше форма, тем проще структура SQL-запроса, но сложнее условия фильтровки (WHERE, GROUP BY, HAVING)

Сообщение от pokerface

но в моём варианте пакет документов с ИЛИ в одной строке и нужно просто найти 1 совпадение на всю строку
а в твоём чё делать? придётся where packets "из одной лодки" как-то указывать

еще раз мой вариант схемы:

bank (id, name)
package (id, name)
doc (id, name)

bank_package (id, bank_id, package_doc_id)
package_doc (id, package_id, doc_id)

и сам запрос:

SELECT

   DISTINCT

/* что нужно выбрать? имя банка? */

   bank.name

FROM

/* связываем все таблицы, хотя для выборки имени банка таблица package лишняя в запросе, можно убрать ее */

    bank b
    INNER JOIN bank_package bp ON b.id=b.bank_id
    INNER JOIN package_doc pd ON pd.id=bp.package_doc_id
    INNER JOIN package p ON p.id=pd.package_id
    INNER JOIN doc d ON d.id=pd.doc_id

WHERE

/* какие условия нужно вписать? у клиента есть только трудовая? */

    d.name = 'трудовая'

[xanxy]

Сообщение от pokerface

как-то так:
разбить банк на пакеты и хранить в виде:
Паспорт
2-НДФЛ
Загран/ВУ/ИНН/СНИЛС/ОМС
СТС (4 года)/Загран (12 мес)/ДМС/ТК

потом найти те пакеты, которым удовлетворяют мои документы
и найти те банки, в которых ВСЕ их пакеты удовлетворены

table packets:
bank packet pass ndfl zagran vu inn snils oms sts zagranT dms tk
sber   1      1    1     0    0  0    0    0   0     0     0   0
sber   2      1    0     1    0  0    0    0   0     0     0   0
sber   3      0    0     1    1  1    1    1   0     0     0   0
sber   4      0    0     0    0  0    0    0   4     12    1   1

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

Это не решить одним грамотным запросом в БД Для того что бы опять требования банка, тебе нужно тупо просмотреть ВСЮ таблицу. Либо вести отдельную таблицу с "требованиями" банков. И каждый раз ее пересматривать при вставке нового документа.

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

[pokerface]

Сообщение от xanxy

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

Это не решить одним грамотным запросом в БД Для того что бы опять требования банка, тебе нужно тупо просмотреть ВСЮ таблицу. Либо вести отдельную таблицу с "требованиями" банков. И каждый раз ее пересматривать при вставке нового документа.

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

из таблицы клиентов, да, в которой его документы указаны
я и работаю над структурой в данный момент, ты же её и процитировал )

Сообщение от chesser

bank (id, name)
package (id, name)
doc (id, name)

bank_package (id, bank_id, package_doc_id)
package_doc (id, package_id, doc_id)

зачем ты разделяешь банки и доки в пакетах по разным таблицам?
чем мой вариант плох?
если у тебя выкинуть package из запроса, как ты говоришь, то получится так?
doc (id,package,name)

[xanxy]

Сообщение от pokerface

именно
я и работаю над структурой в данный момент, ты же её и процитировал )

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

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

Тебе надо просто вести статистику банков. Но это отдельная задача. Она решается отдельно от хранения доков.