afbeeldingen wil je op zich niet in een DB zetten, tenzij je er hele goede redenen voor hebt. Wat je imho beter kan doen is zorgen dat de images een unique filename hebben en de filename opslaan in de database.quote:Op zondag 13 maart 2005 20:10 schreef Swetsenegger het volgende:
Ok, dillema.
Ik ben een site aan het bouwen voor een makelaar. Hierop moet hij natuurlijk nieuwe woningen kunnen plaatsen.
Per woning komen er 5 foto's in 2 formaten (thumb en iets groter)
Ik ga er in ieder geval 2 tabellen van maken, 1 met de omschrijving, adres, prijs etc van de woning en dan een tabel foto's.
Maar... hoe ga ik het doen. upload ik de originele foto's, zet ik die in een BLOB (1 foto per row) en laat ik php resizen bij het uitlezen van de tabel...
voordeel: lekker snel 5 foto's uploaden.
nadeel, trager aan de zichtbare kant.
OF upload ik de foto's, resize ik in twee formaten en zet ik deze twee formaten per row in twee blob's (1 foto per row in 2 sizes).
voordeel, snelheidswinst aan de zichtbare kant
nadeel, vertraging bij uploaden.
OF resize ik de foto's en maak 10 blobs per row
voordeel snelheidswinst zichtbare kant en eenvoudiger scripten voor de zichtbarekant
nadeel, upload proces grote tabellen
vergeet ik iets?
Aangezien er heel veel verloop is, is het een stuk eenvoudiger om ze in DB te zetten dan bij elke wijziging EN een record te verwijderen EN 10 afbeeldingen te unlinken.quote:Op maandag 14 maart 2005 07:56 schreef rickmans het volgende:
[..]
afbeeldingen wil je op zich niet in een DB zetten, tenzij je er hele goede redenen voor hebt. Wat je imho beter kan doen is zorgen dat de images een unique filename hebben en de filename opslaan in de database.
Op zich is het deleten van een record en het deleten van een aantal images niet echt de moeite, zeker niet als je dit in een kleine procedure/ functie heb vastgelegd, dan is het een kwestie van eenmalig schrijven en vervolgens netjes aanroepen.quote:One of the classic "right" applications where images should be stored in the database is when the filesystem overhead outweighs the database query overhead.
We built an image database for icons and "smilies" and other very small images. This site gets about 2,000,000 requests a day for these images. The database delivers them without blinking. The file system version was so overloaded that the consultant's answer to the problem was a $250,000 storage device to put a couple dozen spindles under the I/O.
We told the customer that we would do the project for free if performance did not improve to a satisfactory level (one of my designers was absolutely certain the database design would outperform the filesystem version). We were paid $50k for 2 weeks work and the customer was thrilled with the results.
It's all about what tools are appropriate for the application at hand.
Ja ik had ook op yapf een goede "don't" gevonden.quote:Op maandag 14 maart 2005 20:51 schreef rickmans het volgende:
Zie de volgende artikelen:
http://www.sitepointforums.com/showthread.php?s=&threadid=38728
http://www.zend.com/zend/trick/tricks-sept-2001.php
En zich dekt deze quote de afweging die je zou kunnen/ moeten maken
[..]
Op zich is het deleten van een record en het deleten van een aantal images niet echt de moeite, zeker niet als je dit in een kleine procedure/ functie heb vastgelegd, dan is het een kwestie van eenmalig schrijven en vervolgens netjes aanroepen.
1 | mysql_query("SELECT * FROM users WHERE permission = '!1' ORDER BY username"); |
1 | mysql_query("SELECT * FROM users WHERE permission != 1 ORDER BY username"); |
nee, maar wat dan als er effectief 0 rijen zijn? dan kunne het er 0 of 1 zijnquote:Op donderdag 17 maart 2005 15:23 schreef danko het volgende:
yup, alleen geeft ie dan 12 users terwijl het er 13 zijn... kan het zijn dat ie op 0 begint te telle als ik 'SELECT COUNT(user_id)' gebruik in de sql syntax?
1 2 3 4 | SELECT kleur, COUNT(kleur) AS tel FROM tabel GROUP BY kleur ORDER BY tel DESC |
JAAAA! Ik had die count intussen uitgevogeld, maar ik zat dus met die order by... en $row[COUNT(uri)] werkte wel maar zag er nogal dom uit. Nooit gerealiseerd dat je dus AS kan doen...quote:Op vrijdag 18 maart 2005 02:47 schreef Heliospan het volgende:
[ code verwijderd ]
Ik denk dat dit wel moet werken
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | $voornaam = ''; $acthernaam = ''; $query = sprintf( 'SELECT `voornaam`, `achternaam`'. ' FROM `tabel`'. ' WHERE `username` = "%s"'. ' LIMIT 1' ,mysql_real_escape_string($_POST['username']) ); $query_result = mysql_unbuffered_query($query); while($data = mysql_fetch_assoc($query_result)) { $voornaam = $data['voornaam']; $achternaam = $data['achternaam']; } if(empty($voornaam) && empty($achternaam)) echo "Welkom"; elseif(empty($voornaam)) printf("Welkom mr/mevr %s", htmlspecialchars($achternaam)); elseif(empty($achternaam)) printf("Welkom %s", htmlspecialchars($voornaam)); else printf("Welkom %s %s", htmlspecialchars($voornaam), htmlspecialchars($achternaam)); |
Hangt er vanaf hoe vaak je de voor/achternaam wilt gebruiken. Als het zeg maar de autoredirect pagina is, die volgt op de login POST form, is het logisch om ze niet in de session op te slaan als je de namen verder niet regelmatig gebruikt. Veelal wordt in zulke zaken toch de username gebruikt als algemeen communicatie middel.quote:Op vrijdag 18 maart 2005 11:44 schreef SuperRembo het volgende:
Het lijkt me handiger om dat in de session op te slaan. Dan hoef je de database daar niet elke keer mee lastig te vallen. Bij het inloggen haal je het uit de database en zet je 't in de session. Bij 't uitloggen gooi je 't weer weg.
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |