Archief - Afbeeldingen, dbase of gwn map?

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
G

Gogeta

Legacy Member
In mijn project, moetk bij een bepaald toestel/berekeningen een knop zetten, als ze die klikken, moet de plattegrond/schema vn dat toestel afgedrukt worden/tevoorschijn komen.

Nu kweet ge kunt normaal afbeeldinge ook opslaan in uw DB zelf... is da aan te raden? of tot welke filesize?


greetz

alsook, weet iemand ofr daarn functie voor is om iets te printen? (afdrukken echt e, ni gwn opt scherm printen :D)
T

Tyfius

Legacy Member
Print from javascript. Echt rechtstreeks printen gaat ge waarschijnlijk alleen maar via IE kunnen en dan nog via een ActiveX control. Anders zou het wat misbruikbaar zijn.

En die afbeeldingen, dat hangt allemaal af van wat het doel is. Voor een project op het werk slaan wij bepaalde afbeeldingen momenteel op in een DB en die kunnen makkelijk tot een paar MB groot zijn. Dat hangt af van wat uw DB ondersteunt. De bedoeling bij ons is dat de data uit die DB door 3den kan worden aangesproken, zonder langs onze webserver te passeren en daar afbeeldingen op te halen. Als bij u alles op 1 webserver gebeurt kan je waarschijnlijk beter opteren om dat in mappen te organiseren.
G

Gogeta

Legacy Member
1 server, mysql...
kweet nog niet hoe groot die images gaan zijn (tzulle scans zijn)

ok thx :)
Z

Zir0h

Legacy Member
Een databank wordt over het algemeen enkel gebruikt om data in te stoppen (tekst).
Afbeeldingen in een databank steken zal perfect werken, maar na +100 afbeeldingen zal je db een pak trager werken.

Gebruik uw databank enkel voor bvb de bestandsnaam van je afbeelding op te zoeken en upload je scans in een aparte map op je server.
O

Obliv`

Legacy Member
Ik zou de afbeeldingen ongetwijfeld opslaan in de database als het er niet te veel zijn. Dan haal je jezelf de minste last op de schouders.
W

WHiSPy

Legacy Member
Obliv` zei:
Ik zou de afbeeldingen ongetwijfeld opslaan in de database als het er niet te veel zijn. Dan haal je jezelf de minste last op de schouders.
Klik om te vergroten...

Waarom? Even illustratie naar 'n andere databank: probeer maar eens 'n blob op 'n propere manier uit 'n oracle te krijgen en dan gevisualiseerd. Trust me: da's geen kattepis.

Qua schaalbaarheid is 't volgens mij ook moeilijker: hoe meer gb's je voor je databank begint te trekken, hoe meer je gaat moeten tunen op je queries/rdbms. Je voegt dus nog een operatie toe boven op je disk I/O. Ik zou 't gewoon houden op standaard geoptimaliseerde disk I/O. :)

Always remember: tussen hardware en software is 't 1e per definitie goedkoper.
O

Obliv`

Legacy Member
Het vermijden omdat het moeilijker is vind ik nu niet echt een punt.

Elke techniek heeft hier zijn voor en nadelen. In de database bewaren heeft als voordeel dat je niet moet sukkelen als je iets moet restoren, backuppen, ... als nadeel is er natuurlijk de performance penalty. De voor- en nadelen van op schijf te bewaren zijn dan weer het het omgekeerde van het in de database te bewaren.

Kzou zeggen, doe waar je jezelf het beste bij voelt ;).
W

WHiSPy

Legacy Member
Obliv` zei:
Het vermijden omdat het moeilijker is vind ik nu niet echt een punt.

Elke techniek heeft hier zijn voor en nadelen. In de database bewaren heeft als voordeel dat je niet moet sukkelen als je iets moet restoren, backuppen, ... als nadeel is er natuurlijk de performance penalty. De voor- en nadelen van op schijf te bewaren zijn dan weer het het omgekeerde van het in de database te bewaren.

Kzou zeggen, doe waar je jezelf het beste bij voelt ;).
Klik om te vergroten...

Da's het grote verschil tussen de database-boys en de development-boys, hé. De eerste gaan zeggen: stop alles in de databank en de 2e gaan zeggen van 't niet te doen. :)

Heb er al eindeloze discussies over gehoord op 't werk en ik blijf toch overtuigd van het 2e.
k

killgore

Legacy Member
Je hebt multimedia databases he, die specifiek gemaakt zijn om afbeeldingen en dergelijke op te slaan. Ik ken wel geen open source zaken daarvoor.
Als je standaard postgresql, mysql, ... gebruikt : houdt het er aub buiten.
O

Obliv`

Legacy Member
WHiSPy zei:
Da's het grote verschil tussen de database-boys en de development-boys, hé. De eerste gaan zeggen: stop alles in de databank en de 2e gaan zeggen van 't niet te doen. :)

Heb er al eindeloze discussies over gehoord op 't werk en ik blijf toch overtuigd van het 2e.
Klik om te vergroten...

Inderdaad, die discussies ken ik goed genoeg. Ik heb misschien te lang bij een DBA gezeten :).
k

killgore

Legacy Member
In verband met die performance penalty: kans is groot genoeg dat de database betere performance levert. Mits deze database geoptimaliseerd is dergelijke bestanden kan het zeer goed zijn dat db-caching en dergelijke veel efficiëntere resultaten leveren op een drukke site dan de standaard buffering van uw filesystem.

Maar zoals ik zei: databases die zich echt op zoiets richten zijn nogal beperkt
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan