сложно научить ребенка есть ложкой, если он еще сисю сосет.
Вы не с той стороны начали. Структура хранения в бд должна отражать структуру бизнес объектов, которые задействованы в бизнес процессе. т.е. без описания бизнес-процессов и определения бизнес-объектов, рано говорить о структуре хранения.
По вашей картинке, выходит что таблица orders не содержит цены. т.е. есть клиент и есть книга и это вроде как заказ, но выходит, что если цены на книгу будут в течении времени меняться, то в заказе информации о цене книги на момент покупки нет. нет даты создания заказа, нет статуса, заказа, даты выдачи, даты когда поступила книга со склада в место сбора заказа, а если несколько книг, а если несколько складов, а если территория одного склада китай? нужно все это описывать прежде чем писать структуру.
По складам тоже, что за бред, цена книги на складе, если склад равно магазин, а если магазин отдельно, склад отдельно, цена продажи, а цена закупки, а маржа, а поставщик? это просто не о чем.
Количество книг на складе, кол-во в заказе... в общем не с того конца вы подходите к решению проблемы.
ну если вы используете jQuery, то $('input:checked' ) - это как раз список элементов input, которые checked, так что почему бы вам не использовать $('input:checked').length? https://jsfiddle.net/hwzhynpa/
Дмитрий: или у вас странное представление о платежных системах. вот обзор платежных систем megagroup.ru/payments, при помощи этих систем можно получить платеж от клиента, но ни одна из них не будет хранить деньги у себя и предоставлять информацию о балансе... причем если вы говорите о балансе то это подразумевает и отчет приходов и расходов в том числе. нельзя говорить текущем остатке на счете не получив отчет приходов и расходов за любой период времени... возможно я плохо изучил вопрос, но мне сомнительно что хоть одна платежная система из перечисленных будет заниматься ведением индивидуальных счетов ваших клиентов... учитывая что это ваши клиенты, то конфиденциальность информации о балансе и операциях клиентов должны обеспечивать вы со своей стороны иначе зачем вы нужны, вас просто исключат из участия и ваш бизнес будут вести другие люди.
Дмитрий: Ну если у вас "Услуги" возьмите за пример "услуги оператора сотовой связи", Мегафон, билайн, работают по этой же схеме? и не бывает просто. услуги предоставляются разово или периодически. оплата будет списываться разово или переодически. Баланс автопополнение, доверительный платеж, привязка банковской карты. получение списка операций пополнения и расходов за период. это только CRM, еще есть наверное и операции внутри организации обеспечивающей предоставление услуг. вы все еще мыслите слишком узко для поиска решения.
Дмитрий: смотря что вам нужно, если вы для себя решили что то делать, тогда открывайте учебники по бух учету, если для организации, то смотрите какое из решений 1с закроет работу системы, есть еще SAP, AXAPTA, бог его знает что вам нужно автоматизировать, мыслите шире. начинать нужно с отрасли с определения бизнес деятельности, определения что у вас товар-склад, услуги что у вас? что продаете, что покупаете? какие типы бизнес-операций...
Дмитрий: ну в общем то вы уже дошли до финала лекции бухгалтерского учета, финансовая операция это движение денег со счета на счет, вам осталось почитать про сущность двойной записи и вы сможете уже написать правильный алгоритм движения денег по счетам - план счетов для каждой вашей бизнес операции, которая может отражаться в бухгалтерии несколькими финансовыми операциями. Системы учета денежных средств не дешевые и не универсальные, есть типовые решения привязанные к стандартам законам некой страны и чаще всего в системах это реализовывается. скажем Акт купли продажи, это стандартная операция, под которое можно подготовить типовое решение в рамках страны.
