Jump to content

SQL tabulu apvienošana


codemen
 Share

Recommended Posts

Sveiciens, 

Pašmācības ceļā apgūstu SQL datu bāzes, šobrīd esmu iesprūdis pie tabulu apvienošanas. Ceru, ka kāds varēs iedot padomu, kā šo risināt.

 

Esošie dati - piemēru ņemu no uzņēmuma grāmatvedības sistēmas.

 

 

image.png.5497b7683b052e82a4b7d56f9964f249.png

 

 

 

 

 

Tabula1 - rēķina "galvene", kurā ir basic info par rēķina saņēmēju.

image.png.65ee119c57879757c8165d09808a6223.png

 

 

 

Tabula2 - rēķina rindu detalizēts izklāsts; 

image.png.ef748093f29de987867545f1dfe65195.png

 

 

 

Tabula3 - noliktavas nosūtīšanas "galvene"

image.png.1dc85b901d562b6d9ab0e570202b2d99.png

 

 

 

Tabula4 - nosūtīšanas detalizēts izklāsts

image.png.824bb2816f225b34e37c488b7f04bfc6.png

 

 

 

 

Ar sql pieprasījumu vēlos iegūt visas rēķina rindas, kurām blakus būtu pašizmaksa.

 

Vēlamais rezultāts:

 

image.png.7b1d216931adf95c57cb5d4d0cab7144.png

 

 

Ar šī brīža kodu iegūstu, jo noliktavas nosūtīšanas galvenē ir divi ieraksti, kas atbilst rēķina numuram.

image.png.635e906bf5a4ce82d754798272383953.png

 

Select  tabula1.rēķinanr, tabula2.artikuls, tabula4.pašizmaksa
from 

	tabula1 
	left join tabula2 on tabula1.r.id = tabula2.r.id
        left join tabula3 on tabula1.rēķinanr = tabula3.rēķinanr
        left join tabula4 on tabula3.n.id = tabula4.n.id and tabula2.artikuls = tabula4.artikuls
        

 

Kā korektāk veidot tabulu apvienošanu, lai netiktu ģenerētas papildu rindas?

 

 

Link to comment
Share on other sites

@basicpadoms tur neko nemainīs, jāraksta aptuveni šādi:

 

Select  tabula1.rēķinanr, tabula2.artikuls, t1.pašizmaksa
from
    tabula1
    left join tabula2 on tabula1.r.id = tabula2.r.id
    left join
    (
        select tabula3.rēķinanr, tabula4.artikuls, abula4.pašizmaksa
            tabula3
            left join tabula4 on tabula3.n.id = tabula4.n.id
    ) as t1
    on tabula1.rēķinanr = t1.rēķinanr and tabula2.artikuls = t1.artikuls

 

Skatoties uz tabulu izklājumu, pareizi būtu pieņemt, ka viens artikuls var parādīties vairākos nosūtīšanas dokumentos. Tad daudzums būtu jāsummē:

 

Select  tabula1.rēķinanr, tabula2.artikuls, t1.pašizmaksa
from 
	tabula1 
	left join tabula2 on tabula1.r.id = tabula2.r.id
	left join
	(
		select min(tabula3.rēķinanr) as rēķinanr, min(tabula4.artikuls) as artikuls, sum(abula4.pašizmaksa) as pašizmaksa
			tabula3
			left join tabula4 on tabula3.n.id = tabula4.n.id
		group by tabula3.rēķinanr, tabula4.artikuls
	) as t1
	on tabula1.rēķinanr = t1.rēķinanr and tabula2.artikuls = t1.artikuls

 

Vai šādi:

select min(rēķinanr) as rēķinanr, min(artikuls) as artikuls, sum(pašizmaksa) as pašizmaksa
from
(
	Select  tabula1.rēķinanr, tabula2.artikuls, 0 as pašizmaksa
	from 
		tabula1 
		left join tabula2 on tabula1.r.id = tabula2.r.id

	union all

	select tabula3.rēķinanr, tabula4.artikuls, abula4.pašizmaksa
	from
		tabula3
		left join tabula4 on tabula3.n.id = tabula4.n.id
)
group by rēķinanr, artikuls

 

Edited by camel
  • Patīk 3
Link to comment
Share on other sites

Amatiera jautājumi:

Ja Tev ir rēķina Id, kāpēc citās tabulās, konkrēti, "Nosūtīšanas galvenē" izmanto numuru nevis Id?

Kāpēc vajadzīgs "Rēķins detalizēti", ja, cik noprotu, katrai rēķina galvenei atbilst tikai viena detalizācija?

 

sorry, ja offtopiks, bet, amatieraprāt 😁, tas nav īsti pareizi.

 

Edited by Jurkins
  • Patīk 2
Link to comment
Share on other sites

Man šķiet, ka vispirms vispār būtu jēga apgūt relāciju(neesmu pārliecināts par termina pareizību) datubāzu pamatus. Un tad jau tabulu apvienošanu.

Link to comment
Share on other sites

Domāju, ka var arī iztikt bez subselekta:

image.png.61ea6c8c9aa8b807efacfc149b07a8df.png

Ja ņem vērā @camel minēto summēšanu, tad sanāk šādi:
image.png.c4fddc976a28824667b1b417bfffce49.png
ja grupē pēc rēķina num. un artikula, tad viņām virsū likt min() ir bezjēdzīgi.

  • Patīk 1
Link to comment
Share on other sites

pirms 12 stundām , TOoMoOT teica:

ja grupē pēc rēķina num. un artikula, tad viņām virsū likt min() ir bezjēdzīgi.

yep, ar laiku tās iemaņas zūd, un ja nepiedomā sanāk sarakstīt muļķības

 

tavam sql viena lieka rinda:

select r2.num_rekins, rd.artikuls, nd.pasizmaksa
from nosutisana n
join nosutisana_det nd on nd.id = n.id
right join rekins_detail rd on rd.num_rekins = n.num_rekins
	and rd.artikuls = nd.artikuls
join rekins r2 on r2.id = rd.id
order by r2.num_rekins, rd.artikuls

 

Edited by camel
  • Patīk 1
Link to comment
Share on other sites

5.11.2022. , 12:15, Jurkins teica:

Amatiera jautājumi:

Ja Tev ir rēķina Id, kāpēc citās tabulās, konkrēti, "Nosūtīšanas galvenē" izmanto numuru nevis Id?

Kāpēc vajadzīgs "Rēķins detalizēti", ja, cik noprotu, katrai rēķina galvenei atbilst tikai viena detalizācija?

 

sorry, ja offtopiks, bet, amatieraprāt 😁, tas nav īsti pareizi.

 

Nu jā, normāli  jau katrai tabulai būtu jātaisa savs PK(primary key). Un tad ja vajag relāciju, tad tās PK vērtības ieliek citā tabulā, kā atsevišķu kolonnu. Kautko citu izmantot relācijām varētu teikt ir izņēmuma gadījums.

Edited by spameris
Link to comment
Share on other sites

Pirms 26 minūtēm , spameris teica:

katrai tabulai būtu jātaisa savs PK(primary key)

Ja rēķina numurs ir unikāls, kas ir diezgan loģiski, tad nav nekādas vajadzības pēc rēķina Id. Un tas arī būs PK.

 

edit: iespējams, ir nianses, ja rēķina numurs ir, piemēram, BZK002334-45JQQ stilā, katrs unikāls, tomēr ir jēga taisīt Id, nezinu, varbūt apstrāde paātrinās.

Edited by Jurkins
Link to comment
Share on other sites

Pirms 8 minūtēm , Jurkins teica:

Ja rēķina numurs ir unikāls, kas ir diezgan loģiski, tad nav nekādas vajadzības pēc rēķina Id. Un tas arī būs PK.

 

Tā saucās optimizēšana optimizēšanas pēc, jeb vienkārši nevajadzīga gudrošanās. Kura iekodīs dibenā visnegaidītākajā brīdī, aka pēkšņi vajadzēs rēķina nr, formatu pamainīt, apvienot divas dažādas datubāzes utt.

 

 

  • Patīk 1
  • Atbalstu 1
Link to comment
Share on other sites

Līdz šitādām gurdībām parasti aizdomājas, ja nav procesā efektīvo manageru, kuri gudriniekus laicīgi aptur un ievirza produktīvākā gultnē.

Link to comment
Share on other sites

Paskatījos kā ms accesā šo atrisiināt. Man vēlamais rezultāts sanāca šādā sql variantā:

SELECT rekina_galvene.rekina_numurs, rekins_detalizeti.Artikuls, nosutisana_detalizeti.pasizmaksa
FROM (rekina_galvene INNER JOIN rekins_detalizeti ON rekina_galvene.rek_ID = rekins_detalizeti.rek_ID) LEFT JOIN nosutisana_detalizeti ON rekins_detalizeti.Artikuls = nosutisana_detalizeti.artikuls;

 

Lai iegūtu rezultātu ar query, vienu tabulu var vispār neņemt vērā. image.png.0dd4dfd869ac587cfb27a53c7bb0a7da.png

Link to comment
Share on other sites

Papildus grāmatvedības nianse ko iepriekš nepieminēju- vienādiem artikuliem ir iespējamas dažādas pašizmaksas (konkrētā lieta iegādāta atsevišķos laikos par atšķirīgām cenām).

 

@nrsTev ir taisnība gadījumā, ja sistēma ir tikai viens rēķins, vai artikulam vienmēr ir fiksēta pašizmaksa.

 

 

 

Link to comment
Share on other sites

Pirms 28 minūtēm , codemen teica:

vienādiem artikuliem ir iespējamas dažādas pašizmaksas

Tas jau tev tāpat būs atsevišķā tabulā, kur tu uzskaiti krājumus.

 

 

Link to comment
Share on other sites

Kā arī priekškam artikuls ir divās tabulās?

Ja tev ir rēķins, kurš sastāv no pozīcijām (artikuli), uz nosūtījumu tabula, kura sastāv no rēķiniem. 

Kāpēc nosūtījumam jāsatur atkal artikuli?

Ja saliktu tavas 4 tabulas vienā 'flat failā', tad tev divas kolonas būtu identiskas?

Link to comment
Share on other sites

Ja es pareizi saprotu problemu, tad man loģiskak izskatas šādi

 

 

 

Screenshot from 2022-11-09 21-52-38.png

Edited by AndrisBB
Link to comment
Share on other sites

Karjumi ir vienkarši tas kas ir noliktava.

Katru reizi kad izraksta reķinu ar kautkadu konkretu daudzumu, tad krajumi samazinas par to daudzumu. Nu un preteji, ja kautkas tiek atsutits, tad palielinas.

Rekins var tikt izrakstits bez nosutijuma, bet parasti jau kautkads nosutijums tiks piesaistits. Tapat ari nosutījumā var būt vairāki rēķini.

Tāpat arī katrs ieraksts var saturēt vairakus krajumus ar to pašu artikulu, tik pašizmaksa cita, piemeram vajadzeja izsutig 10 gabalus, bet noliktava bij 6 ar X pašizmaksu un 4 ar Y pašizmaksu.

Edited by AndrisBB
Link to comment
Share on other sites

Pirms 22 minūtēm , AndrisBB teica:

Tāpat arī katrs ieraksts var saturēt vairakus krajumus ar to pašu artikulu, tik pašizmaksa cita, piemeram vajadzeja izsutig 10 gabalus, bet noliktava bij 6 ar X pašizmaksu un 4 ar Y pašizmaksu.

Es gan "ierakstos" turētu vairāk, vai mazāk to ko drukā uz rēķina, tb vidēju cenu no salasītajiem produktiem no krājumiem. Un krājumos ieliktu kolonnu rēķina ID, vai nu sadalītu "debet","credit" kolonnas, vai arī vienkārši liktu salasīto daudzumu ar mīnusa zīmi. Tad sasummējot, sagrupējot Krājumus dabūtu atlikumu.

Link to comment
Share on other sites

Nu var jau katram artikulam pielikt pasreizejo cenu. Nezinu gan kapec rekina vajadzetu rakstit pasizmaksu. 

  • Patīk 1
Link to comment
Share on other sites

Pirms 2 minūtēm , AndrisBB teica:

Nu var jau katram artikulam pielikt pasreizejo cenu. Nezinu gan kapec rekina vajadzetu rakstit pasizmaksu. 

Nu jā pašizmaksu var nelikt, to var sarēķināt. Vienīgi tad tā uzskatāmi un vienkārši redzams cik nopelnīja rēķinā. Bet krājumiem gan manuprāt jāstrādā kā tādai transakciju tabulai kuru sasumējot sagrupējot dabū sava stock atlikumus, naudā, skaitā pa artikuliem utt... Tur pēc FIFO, FILO vai kāviņus tur sauca salasa preci.

  • Kādas šausmas! 1
Link to comment
Share on other sites

Tas jau but kautkadas tranzakcijas, krajumi manuprat ir tas kas tev ir noliktava. X daudzums tas un Y kas cits.

  • Patīk 1
Link to comment
Share on other sites

versatile

Kāpēc izgudrot Amuriku?

Krājums - id, artikuls, nosaukums, statuss (aktīvs/nē)

Klients - id, nosaukums, juridiskā info, adreses. Iespējami dažādi scenāriji.

Rēķina headeris - id, numurs, datums, klienta id, klienta adrese, piegādes adrese, summa, var apmaksas statusu likt, utt.

Līgumi - id, klients, numurs, spēkā no, spēkā līdz, + kaut kāda specifika

Līguma noteikumi - id, līguma id, krājuma id, cena

Rēķina rindas - id, krājuma id, daudzums, cena (pielasās no līguma noteikumiem, bet saglabājas rēķina rindās!)

Krājumu transakcijas - id, krājuma id, transakcijas tips (pārdošana/ražošana/kustība), atsauce (rēķina id/ražošanas id/kustības žurnāla id), daudzums.

Lai rēķinātu pašizmaksu, vajag izdevumu sadaļu. Ja to rēķina citur, tad var izveidot pašizmaksas tabulu, kur norādīt krājumu, pašizmaksu, datumus no kura līdz kuram spēkā.
Pēc tam ņem krājumu transakcijas, un rēķina izmaksas. Tur dažādi scenāriji, parasti jau FIFO, kā arī biznesam jāsaprot, kā vērtē rīcībā krājumus uz pašizmaksas maiņas datumu.
Kaut kā, stipri aptuveni, šādi. un tas ir tikai debitoru/krājumu modulis, vēl vajag kreditorus, ražošanu un savilkt to visu kopā GLā.

Link to comment
Share on other sites

Te jau laikam mācību nolūkos darbojas. Uzdizainēt reālu DB ar pārdomātiem visiem sīkumiem visdrīzāk aizņemtu vismaz 2 nedēļas. Un vēl tad tas būtu tikai sākuma punkts.

Link to comment
Share on other sites

versatile
pirms 2 stundām , AndrisBB teica:

Uzdizainēt reālu DB ar pārdomātiem visiem sīkumiem visdrīzāk aizņemtu vismaz 2 nedēļas. Un vēl tad tas būtu tikai sākuma punkts.

Protams, tas ir S-liknes augšgals un prasa zināmu izpratni par lietām. Bet, ar tādu darbiņu aiz muguras jau var reāli iet iekārtoties kaut kur uz juniora posteni amatā, kur ne tikai brutāli pēc specenes jākodē, bet kur to speceni var palīdzēt domāt, pie kam, visai plašā kantoru lokā.

 

Un jebkuru darbiņu vislabāk mācītie ar reālu vajadzību un use-case prātā.
Atceros, kā vidusskolas laikā programmēju blogu, kas saturu un komentārus glabāja teksta failos. Tak visu varēja i rediģēt, i izdzēst, i vēl sazin ko - par visu padomāts.

Edited by versatile
Link to comment
Share on other sites

Pastāstiet, cik lielu pienesumu dod ģenerēts UUID autonumber vietā? Kāpēc un kādos gadījumos tas būtu vajadzīgs?

Link to comment
Share on other sites

Lai dabūtu relatīvu unikālu UUID?

 

Nezinu kur citi toizmanto, bet vienā produktā pie kura strādāju, katrs ieraksts tiek izveidots uz devaisa. Kautkad tas viss tiek sasinhronizēts ar db uz PC/Servera.

Vienam lietotājam var būt dažādi devaisi. 

  • Patīk 2
Link to comment
Share on other sites

Pirms 20 minūtēm , raivix95 teica:

Pastāstiet, cik lielu pienesumu dod ģenerēts UUID autonumber vietā? Kāpēc un kādos gadījumos tas būtu vajadzīgs?

 

Tieši tikko youtuberis Computer Learning Zone par šo postēja video.

 

 

 

 

Link to comment
Share on other sites

Paldies par diskusiju un ieteikumiem!

 

Kā jau @AndrisBBminēja - tīri mācību nolūkā mēģinu savilkt datus no reālās uzņēmuma grāmatvedības sitēmas.

 

Reāli rēķinu detalizētajā tabulā ir kādas 50 kolonnas ar dažādiem datiem (fifo, SN, datumi, rēķina rakstītājs, grāmatotājs, utt.) bet konkrētajā gadījumā - pašizmaksas šajā tabulā tiek rādītas nepareizi (nezinu kāpēc tā). Tas ir arī iemesls, kāpēc mēģināju cīnīties ar pašizmaksu iegūšanu no nosūtīšanu tabulas, jo tur dati ir korekti.

 

Gala rezultātā - preciza infa par konkrētā rēķina bruto peļņu.

 

Link to comment
Share on other sites

Sarakstīt pareizi tabulas un visus SQL priekā krājumu uzskaite nav triviāla padarīšana. Esmu mēģinājis to darīt bet tā līdz galam visu izdomāt nav izdevies.

 

Realizētai precei ir jārēķina pašizmaksa (iepurkuma cena), atrodot linkus starp realizācijas dokumenta un iepirkumu dokumentu rindām, parasti pēc FIFO metodes. Linkus vēlams turēt atsevišķā tabulā, lai var ātri sataisīt atskaites, piemēram, par krājumu kustību pa piegādātājiem.

 

Tad vēl jādomā kā pareizi rēķināt iepirkuma cenu atgirieztai precei, pēc principa pēdējais ārā pirmais iekšā vai kā savādāk. Vēl jāparedz iespēja labot vecākas pavadzīmes, rakstīt kredītrēķinus, kā rezultātā varbūt jāpārrēķina viss pašizmaksas aprēķins. Nedomāju ka te kāds varētu to visu tā līdz galam izdomāt un nodemonstrēt kā tas darāms.

Edited by camel
  • Patīk 2
Link to comment
Share on other sites

_dunduks_

Un tad vēl papildus inventarizācijas (gan kopējās visu krājumu, gan atsevišķu preču).

Citādi tas ir easy tikai teorijā un 2 nedēļu grāmatvedības kursos.

Link to comment
Share on other sites

10.11.2022. , 11:25, versatile teica:

Kāpēc izgudrot Amuriku?

 

Nu nav jau gan tāda pilnīgi vienāda gadījuma, kas der visam. Jā kā te biedrs minēja skatīts tiek tāds kā "hello world" risinājums. Bet maz ticams ka kautkas no šī te strādās, ja jāapstrādā 100..1000.. vai vairāk sekundē šādu rēķinu, tad iespējams parādītos visādi eksotiskāki risinājumi.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...