Konzept zu Webservice und Webseite

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Konzept zu Webservice und Webseite

    Hi,

    ich muss einen Webservice in PHP machen, der im Prinzip ein Verleih darstellt. Also in der Datenbank sind X Objekte, welche alle verliehen werden können. Das beduetet ich brauch pro Objekt eine Art Zeitleiste. Wenn ich also ein Objekt ausleihe, dann muss diese für den Zeitraum aus nicht mehr verfügbar gekennzeichnet werden. Wenn dann der nächste das Objekt haben möchte, muss der sehen können, dass er es zu diesem Zeitpunkt nicht bekommen kann.

    Wie würdet ihr so etwas konzeptionell angehen? Eine Tabelle mit den Ausleihzeiten als timestmp und einer ObjektID?

    Die Abfrage erfolgt erstmal über eine Webseite. Da könnte ich nach der Auswahl eines Objektes einen SELECT über die ObjectID machen und müßte die TimeStamps irgendwie in einen Kalender eintragen. Dabei stelt sich mir die Frage ob es so einen Kalender wohl zumindest schonmal vorkonfiguriert gibt als HTML oder PHP oder sowas? Ich denke die Darstellung der Zeitleiste und Auswahl des Datums/Uhrzeit wird das komplexeste an der ganzen Sache. Das komplett selber zu machen würde sicher eine Menge Zeit verschlingen.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Hi,

    nein, nicht einfach an der dem Timestamp des Rückgabezeitpunktes fest machen.

    Ein Attribut "verliehen" einführen, das dann technisch auch dafür verwendet wird und explizit auf ja oder nein gesetzt wird, wenn was rein oder raus geht.

    Ausleihzeit ist nur Kosmetik. Ob die Sachen dann auch verfügbar sind ist ne Andere Sache. Oder um Mahnungen zu verschicken. Das ist aber kein Attribut, auf das du dich bei der "Bestandsverwaltung" verlassen kannst.

    Gruß
    Manfred
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Manfred Kreß schrieb:

    Hi,

    nein, nicht einfach an der dem Timestamp des Rückgabezeitpunktes fest machen.

    Ein Attribut "verliehen" einführen, das dann technisch auch dafür verwendet wird und explizit auf ja oder nein gesetzt wird, wenn was rein oder raus geht.

    Ausleihzeit ist nur Kosmetik. Ob die Sachen dann auch verfügbar sind ist ne Andere Sache. Oder um Mahnungen zu verschicken. Das ist aber kein Attribut, auf das du dich bei der "Bestandsverwaltung" verlassen kannst.

    Gruß
    Manfred


    Jein,

    das mit dem Ausgeliehen Tag ist gut. Aber das Ausleihen wird immer frühzeitig geplant. Ist also nicht wie beim Videoverleih das einer kommt und das Dingen mitnimmt, sondern einer sagt "Ich brauche das dingen am 14.Oktober 2013 um 9Uhr für 3 Tage". Es kann dann eben auch gut sein, dass danach noch einer kommt und sagt "Ich brauche das Dingen am 12.Oktober 2013 für 5 Tage". Da muss dann klar sichtbar sein, dass das nicht gehen würde und der Termin muss abgelehnt werden.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Also ICH würde...

    ----
    Tabelle mit Artikeln

    Tabelle mit Kunden

    Tabelle mit Ausleihzeiten
    ----

    Artikel hat eine 1:1 Relation zu einem Kunden. NULL Artikel ist z.Zt. verfügbar oder eben ein Kunde, also gerade verliehen (oder in Wartung...)

    Kunde ist halt Kunde

    Ausleihzeiten, hat natürlich einen Start- und Endstempel eine Relation auf Artikel und eine auf den Kunden

    ....

    Du kannst jederzeit beliebige Ausleihzeiten für Kunde und Artikel hizufügen und anzeigen.

    Wird das Ding tatsächlich ausgeliehen oder zurück gebracht, wird beim Artikel "Kunde" gesetzt bzw. gelöscht.

    Du kannst abfragen, welche Artikel xy gerade geliehen hat, welche er wann reserviert hat, wann welcher Artikel reserviert ist...
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Ja, fast genau so, einziger Unterschied: Statt eines Kundenflags beim Artikel würde in der Tabelle Ausleihvorgänge (m:n Relation zwischen Artikel und Kunde) geplante Ausleihe und Rückgabe sowie tatsächliche Ausleihe und Rückgabe unterbringen.

    Edit: Kalenderwidgets und passende Tutorials gibt's jede Menge. Ist nicht so schlimm, wie man denkt.
    Multigrad - 360°-Produktfotografie für den Mac

  • Bleibt das Problem wie man die Ausleihzeiten am besten Webtechnisch darstellt aber da werde ich wohl mal in einem HTML Forum oder so rumfragen müssen.


    Ein wenig CSS (v0-v3 je nach Browser) mit etwas HTML dazu ne kleine Portion JQuery die den PHP samt MySQL befeuert welche halt JSON via REST ausspucken. Und einen großen Eimer zu kotzen. Also wie immer...

    EDIT: Hab letzte Woche ein Wenig an meiner Website optimiert und u.a. ne CSS3 Animation auf der Startseite eingebaut - daher bin ich wohl diesbezüglich etwas gereizt.
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Achso ja,

    schau dir mal JQuery UI an. Damit kannst du dir vielleicht ne Browser (JS) Anwendung stricken, die einfach, wie iOS und Konsorten, über den Webservice arbeitet und du brauchst nicht extra nochmal ne Webanwendung (so mit dynamischen Seiten erzeugen). Ist ne feine Sache - braucht halt etwas mehr Rechenzeit im Browser, scheitert meist, wenn Content von Suchmaschinen gefunden werden soll - aber reduziert Webtraffic und Entwicklungsarbeit, und funktioniert halt schicker als ne Website.
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Es gibt dafür eine Berufsgruppe. Diese nennt sich "Datenbankdesigner". Spätestens wenn weiter Features dazu kommen, hängt man sich meistens auf wenn man nicht alles richtig macht.
    _____________________________
    Alle Angaben ohne Gewähr :)

    On the internet you can be anything you want. It's strange that so many people choose to be stupid.


    Superbientem animus prosternet

  • Alex schrieb:

    Es gibt dafür eine Berufsgruppe. Diese nennt sich "Datenbankdesigner".
    Spätestens wenn weiter Features dazu kommen, hängt man sich meistens auf wenn man nicht alles richtig macht.


    Das ist richtig. Allerdings sollte für jemanden, der aufwendige Software programmiert die Struktur einer MySQL-Db eine eher kleinere Hürde darstellen. Das Ganze ist ja eigentlich nur ein logisches "Problem".
    Ich bin gegen Signaturen!!!

  • Das Projekt ist als solches ein abgeschlossenes System mit klaren Anforderungen. Da wird nichts wachsen. Es ist auch technisch jetzt nicht besonders anspruchsvoll. Nur sehr viel Fleißarbeit....

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Ich würd auch noch ne Tabelle für "Artikelklassen" einführen. Also wenn die z.B. 5 MacBook 15" im Verleih haben, gibt es eine Klasse MacBook 15", da kommt dann die Beschreibung etc., eben alles was die MBs gemeinsam haben. Ein konkreter Artikel hat dann wieder eine Relation auf die Artikelklasse plus eben die Sachen, die einer konkreten Instanz gehören (Seriennummer, Verleihnummer, Anschaffungsdatum...).

    Hoffe das ich mich einigermaßen Verständlich ausgedrückt habe...
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Ja danke,

    die Tabellen für die Artikel an und für sich werden eh etwas komlexer als eingangs beschrieben. Aber da ist das Konzept soweit klar. Mir ging es jetzt nur um diese Timeline und wie man das am besten abbildet.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    Ja danke,

    die Tabellen für die Artikel an und für sich werden eh etwas komlexer als eingangs beschrieben. Aber da ist das Konzept soweit klar. Mir ging es jetzt nur um diese Timeline und wie man das am besten abbildet.

    Gruß

    Claus


    Mein Vorschlag hat Dir wohl nicht zugesagt? Hast Dich wenigstens nicht dazu geäußert.

    root.hocas.de/demoseiten/timeline/timeline.html

    Gruß
    Bernd
    Ich bin gegen Signaturen!!!

  • Hi Bernd,

    das ist zwar optisch ganz witzig aber nicht besonders funktionionell. Wie soll denn der User sich da einen Tag aussuchen an dem er das Tool verleihen will. Ich denke eine Ansicht wie in iCal wäre deutlich praktischer.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Google "calendar js" erster Treffer: arshaw.com/fullcalendar/ MIT License, alles gut.

    Ich bin aber inzwischen übergegangen, wenn ich JavaScript "widgets" brauche, die komplett selber zu schreiben, weil es sich mit Integration (u.a. auch Design) und Sonderbedürfnissen einfacher macht.
    Obiges müsstest Du ja auch wieder ordentlich anpassen... Aber wenn man sich erstmal in JavaScript (oder besser, Coffeescript) verliebt hat, geht sowas relativ schnell, ich würde mutig schätzen für so ein widget bräucht ich drei Arbeitstage.

    Datenbank-Design find ich fast etwas komplizierter, das will wohl überlegt sein. Kommt auch etwas auf den Umfang der Daten an, etwa für 1000 Produkte die im Schnitt 200 Tage im Jahr geliehen sind, hat Deine "Ausleihzeit" Tabelle 200.000 Einträge pro Jahr, gegen die Du jedes mal JOINen willst. Und so weiter und so weiter.

    EDIT: Hab das obligatorische "PHP? Meinst Du das ernst?!" vergessen :P
    ♥C++

  • Hi Zerm,

    ja das ist wahr das mit dem umdesignen. Das ist eh immer das blödeste das Coporate Identity hinzubekommen. Da sitzt man Tage nur am Aussehen und hat noch keine Funktionalität.

    Es werden eher maximal 100 Produkte (glaube sogar nichtmal das) und pro Produkt maximal 50 Ausleihzeiten (1 pro Woche). Performance sollte also eigentlich keine Rolle spielen.

    PHP ist vorgegeben. Da gibt es nichts dran zu rütteln.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)