Klanten database maken

Status
Niet open voor verdere reacties.
D

davoezzz

Gebruiker
Lid geworden
28 sep 2011
Berichten
86
Beste Helpmij.nl lezers,

Ik zit in de volgende situatie:

Ik moet een online(web based) platform/database maken waarin klanten in kunnen loggen en hier hun persoonlijke bestanden(foto's) kunnen zien.
Het moet gebruiksvriendelijk en gemakkelijk werken.

Het moet beveiligd zijn, en het moet via een webbrowser te openen zijn..

Weten jullie hiervoor een oplossing?


Met vriendelijke Groeten,

DaVoezzz
 
Vraagjes

Het hoeft niet per sé een database te zijn? In plaats daarvan mag het ook een platform zijn?

Gaat het alleen om foto's?
Of moeten er ook andere gegevens worden opgenomen?
Toelichting: foto's kunnen als (bijv.) JPEG.bestanden in een afgeschermde map worden gezet. Daar heb je geen database voor nodig.
Als bij elke foto ook individuele gegevens van de maker of van het onderwerp moeten worden opgenomen, heb je meer aan een database.
​

Moeten de 'eigenaren' van de foto's deze zelf uploaden of is het niet van belang hoe die foto's op hun plaats komen?
 
Het gaat erom dat ik als beheerder foto's kan plaatsen zodat elke klant individueel in zijn map kan kijken en hier foto's uit kan halen. Het moet niet mogelijk zijn dat klanten foto's kunnen uploaden of verwijderen, alleen bekijken dus. Verder wil ik bij elke foto een eventuele toelichting kunnen geven. De klanten moeten alleen toegang kunnen krijgen tot hun foto's Doormiddel van een inlog die is beveiligd(SSL).
 
Wat voor server (apache? windows/linux?)? wat voor scripting framework (ASP.NET/PHP/RUBY)?

Database vloeit voor een deel uit de andere keuzes die je maakt. Indien het alleen foto's en eventueel wat gerelateerde content zijn, kan je database heel eenvoudig opgezet worden.
 
De server is Apache, en het Framework PHP.

Eventueel later over gaan op Windows server en daar op PHP gaan draaien.
 
Als je een search doet op:

"php script photo gallery"

Vind je al een hoop scripts waar je uit kunt "lenen" zoals scripts voor het maken van thumpnails, opmaak, etc. Als je aparte directories aanhoud per klant, hoef je zelfs alleen nog een inlogsysteem toe te voegen (zie ook opmerking tecsman over noodzaak database)
 
Maar als ik in de toekomst een paar honderd klanten heb. Is het een beetje onoverzichtelijk om zelf al deze directories aan te maken. Is er geen bestaand systeem waarmee ik dit kan realiseren(liefst opensource) Ik heb zitten kijken maar Pydio, maar het probleem is dat ik daar te veel functies in vind zitten die de klant niet zou moeten kunnen zien.
 
Ik zou in ieder geval een database gebruiken met een tabel met klantgegevens.
Ik zou ook een tabel overwegen met de klant_ID gekoppeld aan de namen van zijn foto's.

Tenslotte zou ik de foto's zelf in een aparte map plaatsen, de afbeeldingsnaam beginnend met de gebruikers-ID gevolgd door een seperator (-, _, %, &, $) en een unieke naam.

Je hebt het over SSL, kunnen we daar uit op maken dat je een geldig certificaat hebt voor beveiligde verbindingen ?
 
SSL heb ik geen certificaat voor, en gaat dus ook niet werken.

Kunnen jullie mij weg wijs maken hoe ik deze foto's dan zo online kan krijgen zodat ik ze dmv een login en ww kan benaderen? En dan niet alle, maar alleen de foto's die aan de klant gekoppeld zijn.
 
In principe is er geen probleem om 100'en directories te hebben. Ook het aanmaken en beheer hiervan kun je makkelijk met scripts ondervangen.

Je klanten zien alleen de mogelijkheden die je hun geeft via je scripts, dus het feit dat je wat anders gebruikt in de backend is eigenlijk geen probleem.
 
Oke ik zal het nog iets duidelijker zeggen, misschien helpt dat:

Er moet een pagina komen waarop mensen in kunnen loggen.
Deze login moet gecontroleerd worden en kloppen met de gegevens uit een database.
De database heb ik.
De domeinnaam ook.
Apache/PHP heb ik.

Nadat mensen in hebben gelogd moeten ze doorgestuurd worden naar een pagina waarop zij de foto's vinden die ik aan dat account heb gekoppeld.

Weet iemand hoe ik dit kan realiseren? Zo ja, hoe?
 
Is het een optie dat jij de foto's middels FTP op de server plaatst of moet dit via een soort backend gebeuren ?
 
Dit is zeker een mogelijkheid. Maar het moet wel klantvriendelijk eruit zien en dus niet zoals de gemiddelde FTP client. Ik wil een preview van de ge�ploade foto's kunnen tonen gelijk na het inloggen. Zie het gewoon als een soort foto album voor de klant.
 
Je haalt front-end en back-end door elkaar. Zoals ik boven al aangaf, dat jij FTP gebruikt wil niet zeggen dat je klanten dat ooit hoeven te zien. Jij upload via FTP, de klanten downloaden via HTML
 
Als dat zou kunnen zou dat top zijn. Maar hoe realiseer ik zoiets? Kan iemand mij daar in weg wijs maken?
 
Ik heb toevallig pas een fotoalbum systeempje gemaakt.
Je maakt in je dtb deze tabellen:
users <al je klaten, naam, email en de rest EN een UserID
photos < PhotoID, PhotoName, PhotoExt, PhotoDesc
albums <AlbumName, AlbumID, AlbumDesc
PhotoAlbum < PhotoID, AlbumID
UserAlbum < AlbumID, UserID

Je laat foto's uploaden dmv php upload: http://w3schools.com/php/php_file_upload.asp
foto krijgt een ID. Je maakt een album aan. Je stelt in welke foto (id) bij welke album(s)(id) horen (PhotoAlbum). Je stelt in welke user(s) (id) welke album(s) (id) mogen zien. In php verwerk je dit dmv joins http://w3schools.com/sql/sql_join.asp . Alle foto's krijgen een unieke random naam gemaakt door php.
Nu staat er in photos een foto met ID 1, naam hejfhhdj en extensie .jpg. Php zet dit achter elkaar, met /fotos/ ervoor. Zo hoef je maar 1 mapje te hebben.
Nogal vaag uitgelegd. Als je interesse hebt leg ik het wel duidelijker uit.
Voordeel hiervan tegenover allemaal mapjes is dat je 1 foto aan meerdere users kan laten zien en je beschrijvingen etc kan toevoegen.
Upload systeem kun je ook nog heel erg fancy maken met ajax en alles, maar dat is weer een heel verhaal

toevoeging:
Als je niet met albums werkt kun je dat er natuurlijk een gemakkelijk uit slopen.
Hier is een .docx'je met een duidelijkere uitleg over hoe de dtb uit gaat zien: Bekijk bijlage photos.docxBekijk bijlage photos.docx
 
Laatst bewerkt:
In principe is er geen probleem om 100'en directories te hebben
Klik om te vergroten...

Daar zijn wel degelijk problemen mee, het filesystem is in principe een flatfile database en daarin wil je niet teveel subnodes in een node hebben. Er zijn op het net hele verhandelingen te vinden die uiteggen welke voordelen de diverse bestandsystemen hebben, zoek en lees. (en beslis om niet meer dan 200 subnodes per node te maken)

Een database is in dit geval sowieso noodzakelijk. Sla de bestanden op disk op onder alleen het id van het record uit de database, geen extensie, en gebruik absoluut(!!) nooit (een deel van) de originele naam van het bestand. Hackers kunnen dat misbruiken.

Lees voor het databaseontwerp eerst een tutorial over hoe je databases ontwerpt.
Het uploaden zou je via FTP kunnen doen, maar dan moet je ergens een knop hebben waarmee je aangeeft dat je de bestanden hebt geupload zodat je website ze kan verwerken.
Als het op een website moet dan zou ik absoluut bij apache blijven. Windows is ook tegenwoordig nog niet echt het prettigste platform om op te hosten (los van dat het vaak duurder is dan linux).

En google nog eens wat rond, wat je zoekt is een fileshare tool, het heeft feitelijk niets met een gallery te maken (buiten dat je stomtoevallig begint met plaatjes)
 
@pgvincent. Geen van die nadelen gelden eigenlijk voor een situatie waar iemand minder dan 1 file per minuut moet verwerken. Ik begrijp de redenen om op een full performance server rekening te gaan houden met deze verschijnselen, maar niet echt voor iemand die net begint met het opzetten van een dergelijke service. Vanuit de klant gezien is een delay van 1 ms voor iemand die een grote foto download gaat beginnen ook geen echte reden om niet gewoon veel directories te hebben.

Laat ik het dan anders verwoorden: "voor deze toepassing is er geen enkel praktisch probleem om 100'en directories te hebben (op een goede linux server)". Het maakt het beheer veel eenvoudiger en de maintenance structuur platter. Mocht deze site naar meer dan 1 access per seconde gaan in de toekomst dan kan de TS tegen die tijd vast iemand betalen om aanpassingen te doen ;)
 
Laat ik het dan anders verwoorden: "voor deze toepassing is er geen enkel praktisch probleem om 100'en directories te hebben (op een goede linux server)".
Klik om te vergroten...

Op het moment dat jet 100en directories hebt zit je sowieso fout. Los van de performance (die echt griezelig kan dalen, ik praat over minuten om tien bestanden te wissen) is het ook volkomen onbeheerbaar. Mensen kunnen niet omgaan met lange lijsten, het is veel makkelijker als de lijst van directories één, hooguit twee schermen lang is en logisch is opgebouwd.


Het maakt het beheer veel eenvoudiger en de maintenance structuur platter. Mocht deze site naar meer dan 1 access per seconde gaan in de toekomst dan kan de TS tegen die tijd vast iemand betalen om aanpassingen te doen
Klik om te vergroten...

Tegen die tijd is het waarschijnlijk al te laat. Stap #1 is altijd: zet informatie in een database, en omdat je een databaser toch al met een app benadert maakt het geen drol meer uit hoe diep je je directories laat nesten; jij komt er met e hand toch nooit in.

Automatiseer alles wat je kunt automatiseren, maar ook niet meer dan dat.
 
Ik wil voorkomen dat we volledig off-topic gaan hier, maar de menselijke factor hoeft hier niet in betrokken te worden.

Elke klant kan prima zijn eigen directory hebben, zonder dat een mens de structuur hoeft te zien. Het punt is ook niet wel / geen database maar het neerzetten van de fysieke files voor algemeen beheer.

Als je een dir structtur hebt als zo:

/fotos/klanten/
---/klant1/
---/klant2/
---/klant3/
---/klant2000/

En je doet je dynamische opbouw van je structuur in je framework en de binding van de directory via je klantendatabase dan heeft dat nauwelijks effect op de performance (ext4,htree). In principe hoeft geen echt mens dat ooit te zien. De directory traversal van een fixed path is nauwelijks beinvloed door hoeveel subdirs die in dat fixed path staan.

Als ik dus een file ophaal uit: '/fotos/klanten/klant500/' is dat nauwelijks beinvloed door het feit dat er veel andere subdirs in "klanten" zijn.

Ik krijg een beetje het idee dat we het allebei over iets anders hebben. De originele vraag ging over het feit of alles in een grote vergaarbak moest of dat je veel directories kon gebruiken om de files te organiseren. Het gebruik van een goede database en framework heb ik nooit ter discussie gesteld.
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan