лучший метод - vb.net и mysql

Question

лучший способ объяснить ситуацию как можно короче:

Я делаю ремонтную систему для ювелирной компании. Проще говоря, у меня есть таблица клиента и таблица ремонта. Таблица клиентов содержит информацию о клиентах, а таблица ремонта содержит информацию о ремонте клиентов. Таблицы ремонта и клиента связаны вместе столбцом customer.ID (customer_id в таблице ремонта).

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

Клиент, для которого я делаю эту систему, хотел бы связать ремонт. Пример, если у клиента Джон 4 ремонта в системе. Два ремонта новые, а два завершены. Если они не хотят, чтобы с клиентом связывались до тех пор, пока два новых ремонта не будут ЗАВЕРШЕНЫ , они просматривают все существующие ремонты, отмечают эти два и нажимают кнопку с надписью «ремонт связи».

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

Должен ли я просто сделать еще один столбец в таблице восстановления с именем tied_repairs и включить идентификаторы всех связанных ремонтов, разделенные знаком a; (или любой другой символ)?

Спасибо заранее.

Answer 1

правильный ответ зависит от вашего.

лучший подход

создать промежуточную сущность с именем "order = {id, customer, status, advanced, saveby, editby, отменен by, requestdate, cancelldate, updatedate}

"и" orderdetail = {id, order, orderdetails, обслуживании, status_service, статусу, дате посещения, заметке} "

или используйте это НЕ рекомендуется

логика очень проста

добавлен столбец в repais, который называется порядковым номером

добавлен столбец в repais, который называется servicestatus

добавлен столбец в repais, который называется notshowagain

для поиска клиентов с выполненным заказом

select bla, bla
from customer c

inner join 
(select customerid, ordernumber, count(*) services
from repairs
where repairs.status = {1 | 'A' | your status for entity}
group by customerid, ordernumber
) order
on order.customerid = c.id


left join 
(select customerid, ordernumber, count(*) servicesdone
from repairs
where repairs.status = {1 | 'A' | your status for entity}
and servicestatus = 'COMPLETED'
group by customerid, ordernumber
) orderdone
on orderdone.customerid = order.customerid
and orderdone.ordernumber= order.ordernumber

where  order.services = orderdone.servicesdone

- у вас есть промежуточная таблица «заказ», которую вы можете фильтровать по статусу или дате запроса - процент продвинутых, по посетителям, o показать заметки, которые какие-то технические нашли (в заметках)

теперь вы можете

1.- выполнить sql и пометить регистр как "notshowagain"

2.- сделать пометку пользователем ("notshowagain")

Я предпочитаю второе

Answer 2

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

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

Secnario 1: Если реальное требование таково: «Клиент может сказать, что он не хочет вызываться до тех пор, пока не будут завершены все незавершенные ремонты», тогда все, что вам нужно, это поле в таблице клиента, которое является логическим » не звоните, если какой-либо ремонт не завершен ". Тогда запрос вызова становится примерно таким:

select customername, whatever
from customer
join repair rc on rc.customerid=customer.customerid and rc.completed=true and rc.pickedup=false
where customer.allOrNothing=false
or not exists
(select 1 from repair ri where ri.customerid=customer.customerid and ri.completed=false)

Сценарий 2: Вам действительно нужно связать ремонт в произвольных комбинациях. т. е. клиент может сказать, что он не хочет, чтобы его вызвали на ремонт 1 или 3, пока оба не будут выполнены, и он не хочет, чтобы его вызывали на 2 или 5, пока оба не будут выполнены, но их можно было бы вызвать даже на 4 если ничего из этого не сделано, или для 1 и 3, или для 2 и 5. Казалось бы, что клерк очень сложно вводит и поддерживает данные, но все в порядке.

Вам понадобится новая таблица, назовем ее RepairTies. Эта таблица имеет два столбца: RepairTieId и RepairId. Всякий раз, когда вы создаете такую ​​связь, вы создаете одну запись в RepairTies для каждого ремонта в «связанном наборе». Вы создаете RepairTieId для идентификации набора. Значение RepairTieId ничего не значит само по себе: это просто что-то, что связывает записи о восстановлении - «опорная точка», если хотите. Это необходимо, чтобы вы могли прикрепить все записи о ремонте к чему-то, что не зависит от отдельной записи о ремонте. (Обратите внимание, что вы не хотите связывать ремонт № 2 с ремонтом № 1. Что делать, если есть три связанных ремонта, поэтому вы связываете № 2 и № 3 с № 1. Затем пользователь говорит: «О, подождите, № 1 не должен» Если вы были в этом списке, удалите его. Теперь № 2 и № 3 привязаны к ... чему? Вы не хотите потерять тот факт, что № 2 и № 3 связаны только потому, что № 1 исчез.)

Тогда запрос становится:

select customername, whatever
from customer
join repair rc on rc.customerid=customer.customerid and rc.completed=true and rc.pickedup=false
where not exists
(select 1 from repairtie t1
join repairtie t2 on t1.repairtieid=t2.repairtieid and t2.completed=false
where t1.repairid=rc.repairid)

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

Answer 3

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

Answer 4

Всякий раз, когда ремонт завершен, сделайте оператор выбора в таблице ремонта для CustomerID, где RepairTable.Completed = False.Если результатов нет, добавьте запись в таблицу CallList.Если есть результаты, то ремонтник знает, что у клиента есть еще один открытый ремонт.Единственный способ усложнить этот маршрут - это если клиент отменит ремонт, и в этом случае вам нужно будет выполнить последние завершенные исправления для таблицы CallList, чтобы увидеть, были ли какие-либо вызовы, которые не были вызваны (возможно, поле Returnedможет упростить это).

Answer 5

Мы решили эту же проблему в нашем приложении.

Мы также добавили еще один столбец, но включение ID s, разделенных символом, является плохой идеей для базы данных. Мы скорее сделали это:

У нас была таблица repairs с примерами важных столбцов:

• REPAIR_ID
• CUSTOMER_ID
• REPAIR_STATUS (закончено, занято, или в процентах, или на дате ...)

и мы добавили третий столбец REPAIR_TIE

Теперь все связанные ремонты имеют одинаковый номер для REPAIR_TIE, который будет самым низким REPAID_ID.

Теперь мы можем легко

• привязать ремонт друг к другу (обновите все REPAIR_TIE до самого низкого REPAIR_ID)
• отвязать ремонт (установить REPAIR_TIE обратно на свой REPAIR_ID)
• проверьте, все ли ремонты с одинаковым REPAIR_TIE имеют одинаковый статус (или получите минимальный статус, или количество дней работы, которые все еще оцениваются, или ...)