[PHP/(My)SQL] voor dummies - Deel 41

quote:

Op woensdag 11 april 2007 20:37 schreef Xcalibur het volgende:

[..]

Tof! Alles achter de . is geen probleem, ik ga het proberen!

Edit: is al gelukt ^O^

O-)

quote:

Op woensdag 11 april 2007 20:44 schreef Geqxon het volgende:
[ code verwijderd ]

O-)

ik had em in 1 regel ... maar ik gebruik em dan ook in een in_array() check binnen een functie ;)

Kort vraagje:

Kan ik een maximum grootte voor een mysql definieren en zo ja, hoe?

quote:

Op donderdag 12 april 2007 03:01 schreef Libris het volgende:
Kort vraagje:

Kan ik een maximum grootte voor een mysql definieren en zo ja, hoe?

"MySQL" is de naam voor een relationeel database beheerssysteem dat MyISAM, InnoDB en nog wat andere typen tabellen kan aanmaken. Wil je de maximum grootte (in bytes?) van een database bepalen?

*gromt*

Ik heb hier een server staan waarop apache2 en php draait. Die fungeert als intranet en webbased applicatie servertje. Op dit moment draaien er 3 'domeinen' en die wil ik graag eenvoudiger kunnen benaderen dan server/domein

In mijn host file heb ik dus al voor alle 3 de 'domeinen' het ip opgenomen. Ik kan nu dus volstaan om 'intranet' of 1 van de andere 2 namen in te tikken om op de server terecht te komen. Maar vervolgens moet ik dan apache vertellen wat waar naartoe moet:



Ik krijg nu van apache de error terug dat alle 3 de documentroots niet bestaan als ik na de aanpassing van de httpd.conf de service herstart.

Wat doe ik fout?

@Swetsenegger

De documentroots bestáán wel? Dus je hebt onder je root een map www met daarin intranet, Mac_db_mssql en PID_VID_DB (inclusief hoofd- en kleine letters?)

quote:

Op donderdag 12 april 2007 09:29 schreef JeRa het volgende:
@Swetsenegger

De documentroots bestáán wel? Dus je hebt onder je root een map www met daarin intranet, Mac_db_mssql en PID_VID_DB (inclusief hoofd- en kleine letters?)

Ja... afhankelijk van wat Apache als root ziet.

Ik heb C:AppServ, met daarin /Apache2, /www, /php, etc.
In de www folder staan de genoemde mappen

-edit-
Dit staat in de httpd.conf


-edit2- hmz, ziet hij de apache2 folder dan waarschijnlijk als root, dus

zou wellicht wel werken of denk ik nu te eenvoudig?

[ Bericht 9% gewijzigd door Swetsenegger op 12-04-2007 09:39:46 ]

@Swetsenegger

Nee, dat is de zogenaamde configroot, dus waar Apache al zijn configs gaat opzoeken. Meer informatie daarover vind je hier. Héél eventueel gaat jouw idee wel werken, maar dan moet je de eerste slash weghalen (aangezien die eerste slash wordt gezien als een directory, en dat is in dit geval de root).

quote:

Op donderdag 12 april 2007 09:41 schreef JeRa het volgende:
@Swetsenegger

Nee, dat is de zogenaamde configroot, dus waar Apache al zijn configs gaat opzoeken. Meer informatie daarover vind je hier. Héél eventueel gaat jouw idee wel werken, maar dan moet je de eerste slash weghalen (aangezien die eerste slash wordt gezien als een directory, en dat is in dit geval de root).

Het werkt gek genoeg met die puntjes ervoor dus DocumentRoot ../www/intranet

quote:

Op donderdag 12 april 2007 10:07 schreef Swetsenegger het volgende:

[..]

Het werkt gek genoeg met die puntjes ervoor dus DocumentRoot ../www/intranet

Dat is niet zo gek aangezien je met ServerRoot er dus kennelijk de feitelijke werkdirectory mee instelt dan werken relatieve paden dus net zo goed. Je eerste methode werkte niet vanwege de slash op het begin, die geeft een absoluut pad aan (/ wordt dan vertaald naar C:).

quote:

Op donderdag 12 april 2007 08:53 schreef JeRa het volgende:

[..]

"MySQL" is de naam voor een relationeel database beheerssysteem dat MyISAM, InnoDB en nog wat andere typen tabellen kan aanmaken. Wil je de maximum grootte (in bytes?) van een database bepalen?

Ik heb dus meerdere MyISAM tabellen voor meedere users. En inderdaad, een grootte in (mega)bytes.

Bedankt

quote:

Op donderdag 12 april 2007 10:29 schreef Libris het volgende:

[..]

Ik heb dus meerdere MyISAM tabellen voor meedere users. En inderdaad, een grootte in (mega)bytes.

Dat gaat niet vanuit MySQL ze hebben geen instelling gecreëerd waarmee je makkelijk de databases in grootte kunt beperken. Twee oplossingen:

1) Gebruik quotas en maak de user met quota eigenaar van de database (terwijl MySQL nog wel de database kan lezen). Dan zal MySQL nooit fysiek de database groter krijgen dan de hoeveelheid bytes die het besturingssysteem oplegt.

2) Gebruik passieve controle. Voer om het uur (ofzo) een script uit waarmee je de totale grootte van elke database in kaart brengt. Zodra een database te groot wordt stuur je een mailtje, set je een kolom in een statistiekentabel op true, of wat dan ook

quote:

Op donderdag 12 april 2007 10:16 schreef JeRa het volgende:

[..]

Dat is niet zo gek aangezien je met ServerRoot er dus kennelijk de feitelijke werkdirectory mee instelt dan werken relatieve paden dus net zo goed. Je eerste methode werkte niet vanwege de slash op het begin, die geeft een absoluut pad aan (/ wordt dan vertaald naar C:).

Ok, nou bedankt het werkt
Voor het eerst heb ik virtual hosts werkend gekregen

Ik loop tegen een probleem met MySQL aan waar ik niet uitkom. Ik heb een table die 'news' heet met daarin de velden id, timestamp, title en content. Nu wil ik graag een lijstje van nieuwsitems laten zien, met de nieuwste eerst. Dus ik heb daarvoor deze query:



Nogal recht toe recht aan en dat werkt ook prima. De uitkomst is zoiets:



Maar nu! Het ding is, het timestamp is niet echt een timestamp, maar wordt gemaakt met alleen de dag, maand en jaar. Items die opdezelfde dag zijn geplaats, krijgen dus ook hetzelfde timestamp. En daarmee ontstaat een probleem.

Ergens anders wil ik namelijk ook een lijstje van items weergeven op volgorde van tijd, maar dan alleen de nieuwste tien. Die query ziet er zo uit:



En daar komt dit uit:



De volgorde van de items is nu veranderd, dat is niet de bedoeling!

Ik dacht het op te lossen door behalve naar het timestamp, ook naar het id te kijken. Ik hoopte dat de lijst dan alsnog op volgorde van tijd gesorteerd zou worden, maar bij gelijke timestamps, de hoogte van het id de volgorde zou bepalen. Zo staat dat bijvoorbeeld ook hier uitgelegd.

Echter, als ik dat probeer, met bijvoorbeeld deze query:



Is de output totaal niet wat ik verwacht:



Het lijkt wel precies verkeerd om ofzo :?

Iemand een idee hoe ik wel het resultaat krijg wat ik voor ogen heb?

@Tijn

Aan het resultaat van je eerste query te zien is de volgorde van de ID's (primary keys, PK) niet hetzelfde als die van de timestamp, dus kun je de PK niet in wat voor sortering dan ook gebruiken als het gaat om tijd. Dé oplossing is het verbeteren van je timestamp, eventueel door UNIX_TIMESTAMP() te gebruiken wanneer je een record toevoegt aan die tabel voor zover ik kan zien heb je in die tabel te weinig informatie om het nog te kunnen 'herstellen'.

Als je toch altijd dezelfde volgorde wilt zien, kun je eventueel ook op titel sorteren. Dan krijg je dus een sortering op dag, en vervolgens op alfabet.

Tijn, van welke app zijn die screenshot? Lijkt me erg handig

quote:

Op donderdag 12 april 2007 11:41 schreef JeRa het volgende:

Aan het resultaat van je eerste query te zien is de volgorde van de ID's (primary keys, PK) niet hetzelfde als die van de timestamp, dus kun je de PK niet in wat voor sortering dan ook gebruiken als het gaat om tijd.

Dit snap ik niet. Waarom kan ik niet eerst op volgorde van timestamp sorteren en daarbinnen op id?

quote:

Op donderdag 12 april 2007 11:45 schreef super-muffin het volgende:
Tijn, van welke app zijn die screenshot? Lijkt me erg handig

CocoaMySQL.

quote:

Op donderdag 12 april 2007 11:37 schreef Tijn het volgende:
De volgorde van de items is nu veranderd, dat is niet de bedoeling!

De volgorde is prima, het probleem is dat hij eerst je resultaat LIMIT naar 10 records en dán pas gaat sorteren (die tien records dus) in plaats van de hele batch sorteert en daar de eerste 10 records van pakt.

Dwz, daar lijkt het wel op in ieder geval. Zo goed was mijn MySQL-fu nu ook weer niet dat ik dat zeker weet.

quote:

Op donderdag 12 april 2007 11:50 schreef Litpho het volgende:

[..]

De volgorde is prima, het probleem is dat hij eerst je resultaat LIMIT naar 10 records en dán pas gaat sorteren (die tien records dus) in plaats van de hele batch sorteert en daar de eerste 10 records van pakt.

Dat is onzin.

quote:

Op donderdag 12 april 2007 11:45 schreef Tijn het volgende:

[..]

Dit snap ik niet. Waarom kan ik niet eerst op volgorde van timestamp sorteren en daarbinnen op id?

Dat kán wel, maar je hebt er niets aan. Zoals je uit je eerste screenshot kunt opmaken heeft de volgorde van id niets te maken met de volgorde van de timestamp

edit: de oplossing is dit:

ORDER BY timestamp DESC, id DESC;

Want als je niets aangeeft neemt MySQL ASC aan en dat was zo bij timestamp.

quote:

Op donderdag 12 april 2007 11:51 schreef JeRa het volgende:

[..]

Dat is onzin.

Dat is mogelijk, zoveel verstand heb ik niet van MySQL. Oracle ROWNUM functioneert wel op een dergelijke manier (storend genoeg).

quote:

Op donderdag 12 april 2007 11:54 schreef Litpho het volgende:

[..]

Dat is mogelijk, zoveel verstand heb ik niet van MySQL. Oracle ROWNUM functioneert wel op een dergelijke manier (storend genoeg).

Als je in Oracle zoiets doet:

SELECT * FROM tabel ORDER BY kolom1 ASC, kolom2 DESC LIMIT 10;

Wordt het sorteren toch echt vóór het limiteren uitgevoerd hoor

quote:

Op donderdag 12 april 2007 11:51 schreef JeRa het volgende:

[..]

Dat kán wel, maar je hebt er niets aan. Zoals je uit je eerste screenshot kunt opmaken heeft de volgorde van id niets te maken met de volgorde van de timestamp

edit: de oplossing is dit:

ORDER BY timestamp DESC, id DESC;

Want als je niets aangeeft neemt MySQL ASC aan en dat was zo bij timestamp.

Ah! Maar zo is 'ie dan toch goed? Nu is de volgorde van de getoonde items altijd in orde, zowel met als zonder LIMIT geeft 'ie de nieuwste items eerst en altijd op dezelfde volgorde.

quote:

Op donderdag 12 april 2007 11:45 schreef Tijn het volgende:

[..]

CocoaMySQL.

Dank je wel

quote:

Op donderdag 12 april 2007 11:55 schreef JeRa het volgende:

[..]

Als je in Oracle zoiets doet:

SELECT * FROM tabel ORDER BY kolom1 ASC, kolom2 DESC LIMIT 10;

Wordt het sorteren toch echt vóór het limiteren uitgevoerd hoor

Nee, dan klapt je query omdat LIMIT niet bestaat .