Дизайн и внедряване на база данни в Laravel - Автоматични увеличения, които са обвързани с отделни редове, а не само с една таблица

Имам въпрос, на който може да се отговори теоретично или емпирично, в зависимост от това дали това е било напълно постигнато преди или не.

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

С това всяка фактура, която създавате, ще се увеличава с 1, така че обикновено ще приложим поле AUTO_INCREMENT към идентификатора. Проблемът обаче идва, когато започнем да въвеждаме функционалността за множество клиенти.

Позволете ми да демонстрирам проблема чрез пример:

Клиент А прави първата си продажба и създава фактура за това, която автоматично има идентификатор 1. Докато продажбата е била обработена, той е направил втората си продажба. Когато създава втората си фактура, той забелязва, че нещо не е наред с номерирането на фактурата. Втората му фактура вече има ID 3.

Причината за това е, че клиент Б, който наскоро се е регистрирал в системата, е създал първата си продажба, която е имала идентификатор 2. Сега и двамата клиенти имат неправилно номериране на фактури и това много бързо се превърна в неработещо решение

Трябваше да добавя таблица, наречена invoice_client_increments, която по същество е опорна точка между фактурата и клиента, която съхранява новото увеличение. Въпреки че това работи, работата с него е много разхвърляна.

Когато създавам фактурата, трябва да изтегля последния запис invoice_client_increments за този клиент и да добавя един към него, да вмъкна друг и да го свържа с фактурата. Ако някой изтрие фактура, това увеличение се губи и то няма да се държи както обикновено, а вместо това ще презапише премахнато, когато е създадена фактура.

Има ли по-добър начин за проектиране на база данни, за да се приспособи към това, и по-лесен начин за внедряване на това в Laravel, или правя това, както вече трябва да се направи? Това може да е по-скоро въпрос на най-добра практика, отколкото "Как да направя това?"... Благодаря за отделеното време :)


person matthewc    schedule 17.08.2014    source източник
comment
Не мога да видя проблема, какво не е наред с различни идентификатори?   -  person Issam Zoli    schedule 17.08.2014
comment
Клиентите ще искат техните системи за фактуриране да започват от 1 и да няма пропуски по правни причини. Ако имаше 300 клиента и един създаде първата си фактура като фактура 1489, а втората като 5930, това нямаше смисъл и би объркало клиента.   -  person matthewc    schedule 17.08.2014
comment
Изпуснах php тага и добавих multi-tenant, което може да помогне да се привлече повече внимание от мулти-tenant експертите. Това не е проблем с php.   -  person Mike Sherrill 'Cat Recall'    schedule 17.08.2014


Отговори (3)


С това всяка фактура, която създавате, ще се увеличава с 1, така че обикновено ще приложим поле AUTO_INCREMENT към идентификатора.

DBA обикновено не правят това.

Финансовите приложения обикновено трябва да отчитат всеки номер на фактура. Автоматично увеличаващите се идентификационни номера на всички платформи са гарантирани, че имат пропуски при определени обстоятелства (обикновено връщане назад с оператори за едновременно вмъкване). Не можете да отчетете пропуските, като просто кажете: "О, трябва да е имало връщане назад."

Има два общи начина за подход към вашия проблем.

  • Използвайте метод на Laravel или съхранена процедура, за да върнете следващия номер на фактура за даден клиент. Обърнете специално внимание на нивата на изолация на транзакциите и заключването.
  • Промяна на архитектурата. Споделянето на таблици е един вид архитектура с множество наематели. Това не е единственият вид и често не е най-добрият избор. Когато четете тази свързана статия, имайте предвид, че MySQL база данни се държи по-скоро като схема на SQL Server, отколкото като база данни на SQL Server.
person Mike Sherrill 'Cat Recall'    schedule 17.08.2014
comment
Второто решение има голяма стойност в себе си и предлага напълно различен подход към дизайна на базата данни. Прегледът на статията отвори много вратички и аз ще отговоря правилно, след като я прочетох цялата и я възприех, благодаря. - person matthewc; 17.08.2014

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

като вашето автоматично увеличение е добре, но когато вашият cleint submit е продажба, неговата продажба трябва да се увеличи с единица и номерът на вашата фактура може да изглежда така. incrementNo/CleintReference/CleintsaleNo.

каква е продажбата на cleint no. прави е да добавя 1 всеки път, когато той изпрати продажбата си, тя не започва, когато той е започнал продажбата, по този начин ще знаете коя продажба е кой клиент и вашият клиент ще знае колко продажби е извършил днес.

person arif_suhail_123    schedule 17.08.2014

Ако не сте намерили решението и не е късно, ето какво направих за едно приложение.

Получавах всички поръчки от този конкретен клиент, преброявах ги и след това увеличавах този брой с една, така че винаги започвате за всеки клиент да броите от 0 и след това да го увеличавате с 1.

e.g.

$totalOrders = DB::table('orders')->where('client_id', $id)->count();'

DB::table('invoices')->insert(array('client_id' =>  $id, 'invoice_no' => ($totalOrders + 1)));

Надявам се това да ви помогне :)

person lesandru    schedule 10.09.2014