# Meetings > Ομάδες Εργασίας >  Ομάδα ανάπτυξης AWMN Database...

## Mick Flemm

So με την ευκαιρία που γυρνάμε το Nagios σε database λέω αφού την φτιάχνουμε που την φτιάχνουμε την ριμάδα δεν την κάνουμε μια και καλή να μην γεμίζει ο κόσμος 2 και 3 φόρμες, άλλη για Hostmaster, άλλη για Nagios κλπ ? Επίσης το θέμα εγκαταλήφθηκε όπως είδα εδώ http://www.awmn/forum/viewtopic.php?t=11954 (και η προηγούμενη συζήτηση σχετικά με το τι χρειάζεται να μπει στην βάση κατέληξε δυστυχώς σε flame http://www.awmn/forum/viewtopic.php?t=1 ... sc&start=0 ) οπότε αξίζει να το επανεξετάσουμε.


Μέχρι τώρα έχω 3 πίνακες που περιέχουν πληροφορίες για το Configuration του Nagios και κάμποσους που περιέχουν στατιστικά και πληροφορίες του προγράμματος (αρα που δεν πειράζουμε) από αυτούς (τους πρώτους) 1 είναι ανοιχτός για τροποποιήσεις (οι άλλοι είναι αρκετά Nagios specific - συγκεκριμένα ο ένας περιέχει τις συντεταγμένες στις 2 και στις 3 διαστάσεις και τα εικονίδια για τον κάθε κόμβο που κάποτε θα αλάζουν ανάλογα με το λειτουργικό όπως ήταν στην αρχή και ο άλλος τα services που κάνει monitor το Nagios στον κάθε κόμβο). Πρόκειται για τον πίνακα που περιέχει τα εξής στοιχεία για τον κάθε κόμβο (μέχρι τώρα):

α) Όνομα κόμβου
β) Node ID (θα κάνω ξεχωριστό πεδίο για δαύτο, προς το παρόν μπορείτε να το πάρετε σαν κομάτι ενός μεγαλύτερου string - π.χ. Node #XXΧ router -.
γ) Την IP του router (και αρα το /24 subnet του κόμβου)
δ) Το λειτουργικό του router (προς το παρόν είναι ένα default αλλά θα το αλάξω σύντομα).
ε) Μια δήθεν περιγραφή του router (που τώρα είναι το string που είπα παραπάνω)
στ) Τα parent hosts (στην ουσία πρόκειται για τα hosts που πρέπει να scanάρει το Nagios πριν scanάρει τον συγκεκρημένο, ρίχτε μια ματιά στο tree view στο Status Map να πάρετε μια ιδέα, γενικώς είναι περίπλοκο θέμα τα parent hosts και θα το αναλύσουμε κάποια στιγμή) που από αυτά μπορείτε να καταλάβετε με ποιούς είναι συνδεδεμένος ο καθένας (κάνετε ένα querry για να βρείτε τα parent hosts του κόμβου και μετά ένα querry να δείτε σε ποιούς κόμβους είναι ο ίδιος parent host).

Τι άλλο προτείνετε να μπει στον συγκεκρημένο πίνακα (δλδ τι άλλο χρειάζεται να ξέρουμε για τον κάθε κόμβο, είδη έχω υπόψην μου το Νομός/Δήμος/Περιοχή που χρειάζεται για τον Hostmaster), τι άλλο προτείνετε να μπει στην βάση (π.χ. πίνακας χρηστών) ?

Η βάση αυτή θα hostάρετε στον κόμβο του συλλόγου και θα ανοίκει στον σύλλογο, αυτό το λέω για τους εξής λόγους:

α) Γιατί θα φέρει τα στοιχεία των κόμβων του δικτύου οπότε αφορά τον σύλλογο και όχι κάποιον - ους χρήστες μόνο ( <- τον εκάστοτε κομβιούχο που μπορεί αύριο μεθάυριο να κατευάσει για χψ λόγους τις κεραίες του κλπ κλπ).

β) Γιατί θα πρέπει να είναι ανοιχτή και προσιτή στον καθένα μιας και το δίκτυο είμαστε εμείς ΟΛΟΙ (δλδ. να υπάρχει read access για όποιον θέλει, χωρίς να παρακαλάει ή να ψάχνει κανέναν).

γ) Γιατί μόνο ο σύλλογος μπορεί να εγκυηθεί οτι αυτή η βάση θα διαχειρίζεται δημοκρατικά και όχι ανάλογα με τα βίτσια του εκάστοτε admin (ο οποίος προτέινω να εκλέγεται).

δ) Γιατί ο κόμβος του συλλόγου είναι ο μόνος κοινός κόμβος, δηλαδή κόμβος όλων μας.

ε) Γιατί πρέπει να υπάρχει επιτέλους τάξη και κάποια τυποποίηση για να βγάλουμε άκρη, τυποποίηση που να μην αποφασίζουν 1 και 2 αλλά όλοι (γι' αυτό και γίνεται εδώ αυτή η συζήτηση, για να υπάρχουν και γραπτά και όχι σε κάποιο καφέ που θα ξύσουμε - είναι συμαντικό το θέμα). Να αποφασίσουμε δλδ ένα schema που να μας ικανοποιεί και να το τηρίσουμε από εδώ και πέρα.

στ) Γιατί αν τελικά αποφασιστεί να καταχωριθούν προσωπικά δεδομένα των κομβιούχων, μόνο ο σύλλογος είναι σε θέση να εγκυηθεί για την σωστή διαχείρησή τους - προφανώς αυτά δεν θα έχουν read access χύμα (αν και όπως έχω ξαναπεί προσωπικά διαφωνώ με το να υπάρχουν τέτοια στοιχεία, κόμβους φακελώνουμε όχι ανθρώπους).

Σκοπός αυτής της βάσης είναι να αποτελέσει σημείο αναφοράς για όποιον χρειαστεί να φτιάξει μια εφαρμογή για monitoring ή για ενημέρωση (μιας και θα μπορεί από εκεί να πάρει και την κατάσταση των κόμβων απ' το Nagios), ή για κάποιο calendar ή log ή οτειδήποτε του την δώσει τεσπά και θέλει να γλυτώσει τους χρήστες από το να ξανακαταχωρούνται, καθώς και για τον Hostmaster, όποιος κι αν είναι αυτός.

Αφού υπάρχει ενδιαφέρον ας το βάλουμε μπρώς...

Για αρχή πάρτε ένα προσχέδιο του NagiosDB thingie που έφτιαξα μαζί με ένα dump της db με μερικούς κόμβους από το υπάρχον configuration(με ρέγουλα τις ντομάτες, η php δεν είναι το φόρτε μου ακόμα  ::  ). Είναι ακόμα λιγάκι πρόχειρο και δεν έχει τις αλλαγές που λέω παραπάνω (για το nodeid π.χ.). (How to -> http://www.awmn/forum/viewtopic.php?t=2844&start=120 )

----------


## Mick Flemm

Να συμπληρώσω στο παραπάνω οτι απ' την database του nagios μπορείτε επίσεις να πάρετε τα comments και το downtime (ρίχτε μια ματιά στο schema και θα καταλάβετε).

----------


## Mick Flemm

Προς το παρόν το schema όπως το φαντάζομαι, περιμένω feedback...  :: 

Υπόψην σε gnumeric το έκανα οπότε δεν ξέρω αν είναι 100% συμβατό με excel αλλά πρέπει να είναι Ο.Κ.

Όσα έχουν * είναι προεραιτικά, αλλά αν κάποιος π.χ. δεν βάλει lat/long δεν θα μπορεί να μπει στο Nagios και γενικώς σε όποιο άλλο project χρειαστεί απεικόνηση σε χάρτη. Δεν νομίζω να είναι πρόβλημμα, εξ' άλλου και στο NodeCalendar που τα περνάει κατευθείαν στο maporama έχετε δώσει πάρα πολοί αυτά τα στοιχεία. Αν σας κόβει τόσο πολύ βάλτε το στίγμα παραδίπλα... Παρεπιπτόντως το errorlvl είναι το σφάλμα που θέλετε στα lat/long αν αποφασίσουν κάποια στιγμή να το χρησιμοποιήσουν σε κάποια εφαρμογή.

Στο θέμα των προσωπικών δεδομένων νομίζω συμφωνείτε οτι για να δώσεις π.χ. dns σε κάποιο κόμβο ή να τον καταχωρήσεις στο whois κλπ δεν είναι ανάγκη να βάλεις το τηλέφωνο π.χ. το έχουμε ξεσκίσει το θέμα, ακόμα και στο dc++ βάζουμε τα ασύρματα mail μας. Ας μείνουν προεραιτικά και όποιος θέλει τα δίνει...

----------


## monotone

Μερικές γρήγορες παρατήρησεις:

1. Στα ids βλέπω οτι βάζεις τύπο smallint, πόσα bits είναι το smallint; 16; Δέν είναι καλύτερα να βάλεις μεγαλύτερο size μήπως κάποια στιγμή κορεστεί και ψάχνεστε;

2. Θα έλεγα και η "περιοχή" να γίνει look-up table όπως και ο Δήμος, για να μή βάζει ο καθένας ότι θέλει..

Πώς γίνονται associate τα contacts με τα nodes?

To table Routers δεν έχει primary ID (router_id)

----------


## Mick Flemm

1. Στο awmn έχουμε χοντρικά 100 B Classes, αυτό μας κάνει

100 χ 255 = 25.500 < 65.535 που είναι ο smallint

2. Με το owner_id γίνονται associate τα contacts και με το router_id με τους routers, κάθε κόμβος έχει έναν router κι έναν owner.

Συμφωνώ οι περιοχές είναι predefined, μπορείς να δεις το excelάκι που είχα ανεβάσει κάποτε στo "Γενικά για το AWMN" για να δεις το περιεχόμενό τους. Πρόκειται για την κατανομή των c-classes στην Αθήνα με βάση τον πληθυσμό κάθε περιοχής (credit goes to HarisK & Freskos πριν από πολύυυυ καιρό στο 1ο meeting "τεχνικών" του awmn).

Στο table routers έχω βάλει το router_id αλλά έχεις δίκιο δεν έχω ορίσει promary keys, τουλάχιστον δεν φαίνεται στο schema  ::  I'll do it + λίγο τακτοποίημα όταν ξυπνήσω (γιατι ναι ναι θα κοιμηθώ  ::  )...

Thanx for the feedback  ::

----------


## m0bius

Βασικά θα σου πρότινα να φτιάξεις ένα απλό ER-Diagram πρώτα για να μπορέσεις να ξεκαθαρίσεις τι ακριβώς θες, να ορίσεις multiplicities ώστε να ξέρεις πως να κουμαντάρεις foreign keys και μετά να κάνεις αυτό που έκανες.

Δυστυχώς αυτή την περίοδο έχω exams αλλιώς πολύ ευχαρίστως να σε βοηθούσα. (Εκτός αν θές να περιμένεις κάνα μήνα  :: )

----------


## Mick Flemm

εχμ, με απλά Ελληνικά plz  ::   ::   ::  (καλή επιτυχία στις εξετάσεις σου btw)

----------


## dimkasta

> Βασικά θα σου πρότινα να φτιάξεις ένα απλό ER-Diagram πρώτα για να μπορέσεις να ξεκαθαρίσεις τι ακριβώς θες, να ορίσεις multiplicities ώστε να ξέρεις πως να κουμαντάρεις foreign keys και μετά να κάνεις αυτό που έκανες.
> 
> Δυστυχώς αυτή την περίοδο έχω exams αλλιώς πολύ ευχαρίστως να σε βοηθούσα. (Εκτός αν θές να περιμένεις κάνα μήνα )


Απλά και εύκολα...

Φτιάξε τη βάση σου σε Access και δούλεψε τις "σχέσεις" μεταξύ των πινάκων στο γραφικό περιβάλλον για να γίνει και πιο κατανοητή η δομή σε όλους. 
Εγώ πχ μόνο που είδα το xls βαρέθηκα....  ::  

Για τα types δεν ξέρω αν θα βρείς τα ίδια στην access, απλά βάλτα σαν fields για να φτιάξεις εύκολα το γραφικό.
Με απλά drag n drop sta fields μπορείς να ορίσεις σχέσεις και να φαίνονται ωραία.

----------


## dimkasta

Φτιάξε δηλαδή κάτι τέτοιο...

----------


## m0bius

> εχμ, με απλά Ελληνικά plz    (καλή επιτυχία στις εξετάσεις σου btw)


Τhanks  :: 

Μια βάση δεδομένων είναι ένας αντικατοπτρισμός πραγμάτων και καταστάσεων τα οποία μπορείς να βρείς στον κόσμο μας. 

Το ER-Diagram είναι το λεγόμενο Entity Relationship diagram. Εntities είναι οι οντότητες στη βάση σου που απεικονίζουν καταστάσεις που εμφανίζονται στον κόσμο και relationships είναι οι σχέσεις που υπάρχουν μεταξύ των entities.

Κανονικά τα ER-Diagrams φτιάχνονται με UML (και ορισμένες DBMS είναι σε θέση να δημιουργήσουν τις βάσεις από αυτά τα διαγράμματα - π.χ oracle) αλλά τα πιο απλά είναι αυτά που μπορείς να φτιάξεις θεωρώντας τα entities ως κουτάκια και τα relationships ως ρόμβους. 

Πχ. users (entity) administer(relationship) routers (entity). Η παραπάνω γραμμή σου δίνει 2 πιθανά entities και ένα relationship.

Όσον αφορά τα multiplicities είναι οι σχέσεις μεταξύ των entities-relationships και επί της ουσίας καθορίζουν τι μπορείς να κάνεις σε κάποια από αυτά.

Πχ. Αν θεωρήσεις ότι μόνο ένας user μπορει να κανει administer ένα router τότε το multiplicity αυτών είναι (1,1) που σημαίνει ότι μπορείς τελικά να το υλοποιήσεις προσθέτοντας ένα foreign key στον πίνακα users το οποίο να κάνει reference σε κάποια εγγραφή στον πίνακα routers. Αν από την άλλη όμως θες παραπάνω από ένας χρήστες (>0) να κάνουν administer παραπάνω από 0 routers (multiplicity (0,n)) τότε καταλήγεις στο ότι το relationship administers θα πρέπει να είναι ένας ξεχωριστός πίνακας ο οποίος να περιέχει πχ τα ακόλουθα πεδία:

user_id INT NOT_NULL REFERENCE users(user_id)
router_id INT NOT_NULL REFERENCE routers(router_id)
comment VHARCHAR(256) 

Βασικά είναι ολόκληρη θεωρία το database design αλλά αν τελικά πάρεις μια γενική ιδέα του τι γίνεται θα μπορείς να φτιάξεις τα πάντα.

Ένας πολύ απλός τρόπος να ξεκινήσεις είναι να γράψεις ένα κειμενάκι σχετικά με αυτά που θές να συμβαίνουν στην βάση σε απλά ελληνικα. Όταν τελικά τελειώσεις υπογράμισε όλα τα ουσιαστικά και τα ρήματα στο κείμενο σου. Τα ουσιαστικά αποτελούν πιθανά entities και τα ρήματα πιθανά relationships μεταξύ των entities. (Αν ένα πιθανό entity δεν έχει τόσα πολλά πεδία τότε πάει να πεί ότι ίσως δεν πρέπει να υπάρχει μόνο του ( αλλά μέρος κάποιου άλλου) ή ότι πρέπει να απεικονιστεί σαν relationship.

Τέλος απλά να σου πώ ότι τα στάδια που θεωρητικά περνάς για να κάνεις design μια database είναι τα: Conseptual Design ( Entity Identification, Relationship Identification, Entity Attribute Identification, Relationship Attribute Identification, ER-Diagram ) Logical Design ( Entity Translations, Relationship Translations, Reduncancy checking (functional dependencies) και Normalisation).

----------


## Mick Flemm

Θυμίζει πολύ ένα μάθημα που κάνουμε στο Πανεπι "Object oriented analysis and design", κι εκεί δουλεύουμε παρόμοια. Θα προσπαθήσω να κάνω αυτό που λες, ξέρω τι θέλω να κάνει η βάση και είμαι στο ψάξιμο για την υλοποίηση.

Ευχαριστώ για τις παρατηρήσεις, προχωράω όπως μου είπατε  ::

----------


## monotone

Αν χρειαστείς βοήθεια για το normalisation της βάσης ή οτιδήποτε άλλο just ask..

Πάντως είναι καλή ιδέα να το κάνεις σε Access πρώτα.

----------


## Mick Flemm

Ευχαριστώ όλους παιδιά I'll keep you posted...

----------


## Mick Flemm

O.K. ελπίζω να βοηθίσει το παρακάτω (άργισε λόγω πολών υποχρεώσεων και διαφόρων flames που με κρατούν τον τελευταίο καιρό εκτός forum, πραγματικά βαρέθηκα να ασχολούμαι)...

Το έφτιαξα με το DBDesigner ( http://www.fabforce.net/dbdesigner4/ ) το οποίο εκτός από πολύ όμορφο κι εύχρηστο είναι και open - source.

Ακολουθεί το xml για να το ανοίξετε με το DBDesigner και να δείτε όλο τον σχεδιασμό (ποια πεδία είναι υποχρεωτικά π.χ.) καθώς και μια εικόνα με το σχέδιο σε uml (ER όπως μου είπατε).

Αυτό το ριμάδι με το εν λόγω προγραμματάκι γίνεται κατευθείαν sql script για την MySQL.

Enjoy και θέλω feedback plz για να συνεχίσω...

Ευχαριστώ και πάλι για τις ιδέες σας !

----------


## Achille

Visual DataBasic...

----------


## dimkasta

Με μια πρώτη ματιά καλό σαν υλοποίηση.
Μόνο μια παρατήρηση, στα services.
Kάντο "each service has an admin"
οχι "each admin has a service"

Έτσι ο μηχανισμός της βάσης που αντιμετωπίζει λάθη από μετατροπή ή σβήσιμο εγγραφών που συνδέονται με foreign key σε εγγραφή στον άλλο, θα λειτουργεί σωστά.

----------


## Mick Flemm

Done !

Για όποια άλλη παρατήρηση πείτε μου αμα είναι για να αρχίσω την phpοδουλειά...

----------


## m0bius

Βασικά τυχόν αλλαγές που μπορούν να σου κάνουν τη ζωή πιο εύκολη στο implementation:

με το protocol_id στο servicedefs entity τι εννοείς; Αν είναι κάτι που πέρνει standard τιμές τότε θα σου πρότινα ENUM αντί για smallint. Επιπλέον αν επιμένεις να το έχεις ως protocol_id το protocol_id θα πρέπει να είναι foreign key σε κάποιο άλλο entity που να ορίζονται τα protocols.

Διαφωνώ με το να έχεις στο admins ως primary key το username. Μπορεί κάποια στιγμή στο μέλλον να έχεις δύο admins με το ίδιο nickname και τότε απλά διαλύθηκε το σύμπαν. Πρόσθεσε ένα uid AUTO_INCREMENT στο admins, βάλτο primary και βάζε αυτό σαν foreign στους υπόλοιπους πίνακες.

Τι εννοείς με το parents στο servers; Ο πληθυντικός προσδιορίζει ότι ότι και να εννοείς είναι παραπάνω από ένα. Που σημαίνει ότι με το να τα έχεις όλα στο VARCHAR κάνει το searching δύσκολο. Εδώ είναι χαρακτηριστική περίπτωση ER του στύλ: server have parents κάτι (δεν ξέρω τι εννοείς με το parents) και το have parents είναι ξεχωριστός πίνακας με απλά δύο foreign keys (ένα για το servers και ένα για το κάτι) που μαζί είναι το primary key για τον πίνακα.

Το contacts με το admins μοιάζει πολύ κοινός πίνακας και ίσως θα έπρεπε να είναι σε ένα πίνακα πχ users. Αν τα αφήσεις έτσι δημιουργείς πιθανό functional dependency.

Τα multiplicities μεταξύ των records-nodes, contacts-node, router-node φαίνεται να είναι (1,1) Δηλαδή το λιγότερο ένα το περισσότερο ένα relationship μεταξύ των δύο. Αυτό δεν είναι σωστό γιατί παραπάνω από ένα contacts έχουν ένα node πχ και ένα node μπορεί να έχει παραπάνω από έναν router. Σε όλες αυτές τις περιπτώσεις το multiplicity είναι (0,n) και χρειάζεται για το κάθε ένα relationship ξεχωριστό table.

Βασικά φαίνεται ότι είσαι σε καλό δρόμο αλλά θέλει λίγο προσοχή. Όταν φτιάχνεις την βάση δεν την φτιάχνεις με βάση τι είναι λογικό αλλά προσπαθείς να αντικατροπτίσεις τον πραγματικό κόσμο στα entities και τα relationships γενικά ώστε να μπορείς να ανταπεξέλθεις εύκολα και σε τυχόν αλλαγές.

Τέλος φρόντισε να είναι όλα τα attributes lower case. Είναι πολύ εκνευριστικό να πρέπει να προσέχεις το case στα queries και νομίζω η mySQL είναι case sensitive. (Εξάλλου φαίνονται και πιο καλά)

Τέλος κάτι άλλο πολύ σημαντικό. Όταν φτιάχνεις τον κώδικα θα έρθει η ώρα που θα πρέπει να γράψείς SQL queries για να κάνεις retrieve τα data από την βάση. 

Π.χ Για να δείς ποιούς nodes έχει το contact m0bius μπορείς να κάνεις:

SELECT owner_id FROM contacts WHERE forum_username='m0bius';

Σώζεις το owner_id σε κάποιο variable και κάνεις:

SELECT * FROM nodes WHERE Contacts_owner_id=$owner_id;

Αυτός είναι ο πλεόν λάθος τρόπος για να το κάνεις. Όλη η δύναμη των databases είναι ότι μπορείς να κάνεις selective selects και να αφήνεις την βάση να κάνει compinations μιας και standard θα το κάνει πιο γρήγορα από εσένα. 

Ο σωστός τρόπος θα είναι:

SELECT * FROM nodes, contacts WHERE nodes.Contacts_owner_id=contacts.owner_id AND contacts.forum_nickname='m0bius';


P.S Τέλειωσα τα exams!! Χεχε. Xaotikos θα σε λιώσω σαν κουνούπι  :: 

Edit Edit: Φτιάξε και indexes!

----------


## dimkasta

> Διαφωνώ με το να έχεις στο admins ως primary key το username. Μπορεί κάποια στιγμή στο μέλλον να έχεις δύο admins με το ίδιο nickname και τότε απλά διαλύθηκε το σύμπαν. Πρόσθεσε ένα uid AUTO_INCREMENT στο admins, βάλτο primary και βάζε αυτό σαν foreign στους υπόλοιπους πίνακες.
> 
> Διαφωνώ γιατί ενδεχομένως να χρησιμοποιηθεί κάπου για authentication, οπότε θα πρέπει εκ των πραγμάτων να είναι μοναδικό το username.
> 
> Το contacts με το admins μοιάζει πολύ κοινός πίνακας και ίσως θα έπρεπε να είναι σε ένα πίνακα πχ users. Αν τα αφήσεις έτσι δημιουργείς πιθανό functional dependency.
> 
> Συμφωνώ. Βάλε όλο τον κόσμο σε έναν πίνακα πχ users και όρισε ένα πεδίο user_level_id, το οποίο θα έιναι foreign key σε άλλο πίνακα όπου θα απαριθμούνται οι πιθανοί ρόλοι των χρηστών. Έτσι θα μπορείς να τους βάζεις και εύκολα σε drop box ή ραδιο button.
> 
> Τα multiplicities μεταξύ των records-nodes, contacts-node, router-node φαίνεται να είναι (1,1) Δηλαδή το λιγότερο ένα το περισσότερο ένα relationship μεταξύ των δύο. Αυτό δεν είναι σωστό γιατί παραπάνω από ένα contacts έχουν ένα node πχ και ένα node μπορεί να έχει παραπάνω από έναν router. Σε όλες αυτές τις περιπτώσεις το multiplicity είναι (0,n) και χρειάζεται για το κάθε ένα relationship ξεχωριστό table.
> ...


Δημήτρης

----------


## m0bius

> Διαφωνώ με το να έχεις στο admins ως primary key το username. Μπορεί κάποια στιγμή στο μέλλον να έχεις δύο admins με το ίδιο nickname και τότε απλά διαλύθηκε το σύμπαν. Πρόσθεσε ένα uid AUTO_INCREMENT στο admins, βάλτο primary και βάζε αυτό σαν foreign στους υπόλοιπους πίνακες.
> 
> Διαφωνώ γιατί ενδεχομένως να χρησιμοποιηθεί κάπου για authentication, οπότε θα πρέπει εκ των πραγμάτων να είναι μοναδικό το username.


Εμένα προσωπικά δεν μου αρέσει το username να είναι το primary key. 




> Τα multiplicities μεταξύ των records-nodes, contacts-node, router-node φαίνεται να είναι (1,1) Δηλαδή το λιγότερο ένα το περισσότερο ένα relationship μεταξύ των δύο. Αυτό δεν είναι σωστό γιατί παραπάνω από ένα contacts έχουν ένα node πχ και ένα node μπορεί να έχει παραπάνω από έναν router. Σε όλες αυτές τις περιπτώσεις το multiplicity είναι (0,n) και χρειάζεται για το κάθε ένα relationship ξεχωριστό table.
> 
> To multiplicity είναι λίγο ιδιότροπο σαν υλοποίηση. Ζήτα βοήθεια από κάποιον που ξέρει 5 πράματα παραπάνω όταν θα γράφεις τον κώδικα. Επίσης, το γραφικό σου μοντέλο δεν τα δείχνει αμφίδρομα. πχ ένα router ανοίκει μόνο σε ένα node, αλλά ένα node μπορεί να έχει ένα ή περισσότερα router. Δές πως μπορείς να το υλοποιήσεις, αλλά και να το απεικονίσεις. Θα κάνεις τη ζωή σου πιο εύκολη.


Διαφωνείς δηλαδή ή συμφωνείς σε αυτό που είπα; Δεν κατάλαβα

----------


## dimkasta

Συμφώνησα και επαύξησα...
 ::   ::

----------


## Mick Flemm

> Βασικά τυχόν αλλαγές που μπορούν να σου κάνουν τη ζωή πιο εύκολη στο implementation:
> 
> με το protocol_id στο servicedefs entity τι εννοείς; Αν είναι κάτι που πέρνει standard τιμές τότε θα σου πρότινα ENUM αντί για smallint. Επιπλέον αν επιμένεις να το έχεις ως protocol_id το protocol_id θα πρέπει να είναι foreign key σε κάποιο άλλο entity που να ορίζονται τα protocols.
> 
> Δες στο /etc/protocols για να δεις τα ήδη καταχωριμένα προτόκολα, το άφισα φλου γιατί ενδεχομένως να μπει κάποιο καινούριο προτόκολο, να συμφωνήσουμε π.χ. οτι το protocol με id ταδε είναι π.χ. το DC++.
> 
> Διαφωνώ με το να έχεις στο admins ως primary key το username. Μπορεί κάποια στιγμή στο μέλλον να έχεις δύο admins με το ίδιο nickname και τότε απλά διαλύθηκε το σύμπαν. Πρόσθεσε ένα uid AUTO_INCREMENT στο admins, βάλτο primary και βάζε αυτό σαν foreign στους υπόλοιπους πίνακες.
> 
> Η λογική είναι οτι το authentication και βασικά ότι όποιο άλλο service έχουμε ως τώρα δεν επιτρέπει 2 users με το ίδιο username, κατά την γνώμη μου βοηθάει πολύ αυτή η κατάσταση βλ. 1user - 1nickname. Αν παρατήρισες δε υπάρχουν παραπομπές στο forum, γι' αυτό λογικό είναι να υπάρχει και παρόμοιος τρόπος διαχείρησης των nicknames (ίσως ανέμπαινε uid να ήταν αυτό του forum).
> ...

----------


## m0bius

> Βασικά τυχόν αλλαγές που μπορούν να σου κάνουν τη ζωή πιο εύκολη στο implementation:
> 
> με το protocol_id στο servicedefs entity τι εννοείς; Αν είναι κάτι που πέρνει standard τιμές τότε θα σου πρότινα ENUM αντί για smallint. Επιπλέον αν επιμένεις να το έχεις ως protocol_id το protocol_id θα πρέπει να είναι foreign key σε κάποιο άλλο entity που να ορίζονται τα protocols.
> 
> Δες στο /etc/protocols για να δεις τα ήδη καταχωριμένα προτόκολα, το άφισα φλου γιατί ενδεχομένως να μπει κάποιο καινούριο προτόκολο, να συμφωνήσουμε π.χ. οτι το protocol με id ταδε είναι π.χ. το DC++.


Και θα κάνεις το cross-reference μεταξύ του νούμερου και του ονόματος ανοίγοντας το αρχείο; Ok γίνεται αυτό, φασαρία είναι όμως  :: 




> Διαφωνώ με το να έχεις στο admins ως primary key το username. Μπορεί κάποια στιγμή στο μέλλον να έχεις δύο admins με το ίδιο nickname και τότε απλά διαλύθηκε το σύμπαν. Πρόσθεσε ένα uid AUTO_INCREMENT στο admins, βάλτο primary και βάζε αυτό σαν foreign στους υπόλοιπους πίνακες.
> 
> Η λογική είναι οτι το authentication και βασικά ότι όποιο άλλο service έχουμε ως τώρα δεν επιτρέπει 2 users με το ίδιο username, κατά την γνώμη μου βοηθάει πολύ αυτή η κατάσταση βλ. 1user - 1nickname. Αν παρατήρισες δε υπάρχουν παραπομπές στο forum, γι' αυτό λογικό είναι να υπάρχει και παρόμοιος τρόπος διαχείρησης των nicknames (ίσως ανέμπαινε uid να ήταν αυτό του forum).


Το ξέρω ότι δεν γίνεται να υπάρχουν δύο ίδια usernames αλλά παντού γίνεται με βάση το uid και απλά το username είναι για ευκολία του ανθρώπου.




> Τι εννοείς με το parents στο servers; Ο πληθυντικός προσδιορίζει ότι ότι και να εννοείς είναι παραπάνω από ένα. Που σημαίνει ότι με το να τα έχεις όλα στο VARCHAR κάνει το searching δύσκολο. Εδώ είναι χαρακτηριστική περίπτωση ER του στύλ: server have parents κάτι (δεν ξέρω τι εννοείς με το parents) και το have parents είναι ξεχωριστός πίνακας με απλά δύο foreign keys (ένα για το servers και ένα για το κάτι) που μαζί είναι το primary key για τον πίνακα.
> 
> Το parents είναι μια μεταβλητή στο Nagios που περιλαμβάνει χοντρικά τους κόμβους που είσαι συνδεδεμένος και βρίσκονται ποιό κοντά (λιγότερα hops) απ' τον monitor server, χωρισμένους με κόμα. Έχω βάλει αν πρόσεξες μεγάλο όριο με την λογική οτι μέχρι 7 κόμβοι επιτρέπονται στην συγκεκριμένη μεταβλητή (βασικά όσοι θες αλλά για να μην γίνει κάποιο λάθος το έχω περιορίσει με το σκεπτικό ότι κάποιοι κόμβοι έχουν ήδη 5 link π.χ. και λαμβάνω την ακραία περίπτωση όλοι να ισαπέχουν απ' τον server). Το συγκεκριμένο είναι εργαλείο του Nagios περισσότερο αλλά είναι και χαρακτηριστικό του κάθε κόμβου, οπότε σε περίπτωση που το θέλει κάποιος το παίρνει από εκεί.


Παραμένει λάθος design απλά αν θές να λειτουργεί κοινά με κάτι άλλο είναι λογικό να το αφήσεις έτσι.




> Το contacts με το admins μοιάζει πολύ κοινός πίνακας και ίσως θα έπρεπε να είναι σε ένα πίνακα πχ users. Αν τα αφήσεις έτσι δημιουργείς πιθανό functional dependency.
> 
> Admin μπορεί να είναι και κάποιος που δεν έχει κόμβο αλλά έναν server οπουδείποτε, οπότε υπάρχει διαχωρισμός, δεν μπορούμε να τους βάλουμε στο ίδιο τσουβάλι.


Και πάλι τους διαχωρίζεις μέσα από τους ίδιους πίνακες. Αυτό είναι το λεγόμενο generalisation hierarchy και επειδή είδα το πρόγραμμα που χρησιμοποιήσες (δεν είν κακό) το υποστηρίζει. Δηλαδή φτιάχνεις ένα table users το οποίο μπορεί να χωρίζεται σε common και admins. Αυτό στο ER-Diagram, γιατί όταν φτιάξεις τα tables μπορεί να τα βάλεις όλα σε ένα table και να ξεχωρίζονται από κάποια boolean fields ή κάποιο level ή κάποιο enum. Όταν γράφεις κάποιο application είναι πιο εύκολο να το κάνεις να προσθέτει ένα χρήστη once παρά δύο φορές




> Τα multiplicities μεταξύ των records-nodes, contacts-node, router-node φαίνεται να είναι (1,1) Δηλαδή το λιγότερο ένα το περισσότερο ένα relationship μεταξύ των δύο. Αυτό δεν είναι σωστό γιατί παραπάνω από ένα contacts έχουν ένα node πχ και ένα node μπορεί να έχει παραπάνω από έναν router. Σε όλες αυτές τις περιπτώσεις το multiplicity είναι (0,n) και χρειάζεται για το κάθε ένα relationship ξεχωριστό table.
> 
> Κάθε εγγραφή (για νέο subnet - domain) αφορά έναν κόμβο και κάθε κόμβος ακόμα κι αν έχει παραπάνω από 1 router (πράγμα πολύ ασυνήθιστο καθότι του ανοίκει πάντα 1 subnet) μας ενδιαφέρει 1 router για να κάνουμε monitor τον κόμβο, γιατί να κάνουμε την ζωή μας δύσκολη ?


Δεν την κάνεις δύσκολη με αυτό που σου είπα. Την κάνεις πολύ πιο εύκολη γιατί όταν θα έρθει ο τάδε admin και σου πει ξέρεις, εγώ έχω 3 routers στο node μου και θέλω να τα έχω και τα τρία στην βάση σου, πώς θα το υλοποιήσεις μετά;




> Αν μπορείς να πάρεις το xml και το προγραμματάκι και να κάνεις τις αλαγές που λες θα ήταν ότι καλύτερο, δεν μπορώ να μπω στο κεφάλι σου και προφανώς δεν είμαι τόσο σχετικός με το θέμα. Εξ' άλλου σιγά-σιγά την κάνω από το forum οπότε δεν θα είμαι σε θέση να το συνεχίσω.


Δεν είναι το θέμα να μπείς στο κεφάλι μου, απλά ζήτησες σχόλια και κάνουμε σχόλια πάνω σε αυτό που έφτιαξες. Βασικά πολύ ευχαρίστως να ασχολιόμουν αλλά ήδη αυτή την περίοδο είμαι χωμένος με την πτυχιακή μου και αναγκαστικά αυτό θα έμπαινε σε δεύτερη μοίρα.

----------


## dti

Για να μη γίνονται διπλές και τριπλές δουλειές για το ίδιο θέμα, θα πρότεινα να συνεργαστείτε με τον winner & cha0s, ώστε η awmndb που θα προκύψει να είναι οτι καλύτερο και πιο πλήρες έχει παρουσιαστεί μέχρι τώρα.
Ρίξτε μια ματιά στην awmndb του winner (wireless / internet) όσοι δεν ήσασταν στη χθεσινή παρουσίαση.

----------


## Cha0s

Συμφωνώ με τον Δαμιανό.

Είδα λίγο το Project και είναι πολύ καλό και με μέλλον.
Θεωρώ ότι είναι καλύτερα να αποσυρθεί το nodecal και η λειτουργεία ημερολογίου που έχει να μπει στο project του Νίκου.

Δυστυχώς ο χρόνος με πρόδωσε και δεν μπόρεσα να έχω κάτι αξιόλογο διαθέσιμο και δεν θέλω να σας κρεμάσω.

Συγχαρητήρια για την δουλειά του Winner.

----------


## MerNion

> Συμφωνώ με τον Δαμιανό.
> 
> Είδα λίγο το Project και είναι πολύ καλό και με μέλλον.
> Θεωρώ ότι είναι καλύτερα να αποσυρθεί το nodecal και η λειτουργεία ημερολογίου που έχει να μπει στο project του Νίκου.
> 
> Δυστυχώς ο χρόνος με πρόδωσε και δεν μπόρεσα να έχω κάτι αξιόλογο διαθέσιμο και δεν θέλω να σας κρεμάσω.
> 
> Συγχαρητήρια για την δουλειά του Winner.


Και εγώ συμφωνώ με τον Βαγγέλη... Απ' ότι μου έχει πει και ο Νίκος υπάρχει η δυνατότητα να μπουν σαν modules ότι υπηρεσίες θέλουμε (σίγουρα θα χρειάζονται κάποιες μετατροπές αλλά δεν είναι τίποτα δύσκολο). Εννοείτε ότι θα προσπαθήσω και εγώ να δω πως μπορούν να ενσωματωθούν τα services και ο whois server στην πλατφόρμα του Winner.

----------


## Cha0s

Και το looking glass θα είναι πολύ βολικό να μπει  ::

----------


## socrates

Χαίρομαι που υπάρχει πνεύμα συνεργασίας.

----------


## Cha0s

Και οργάνωσης  ::  

Αν και έμμεσα χαρακτηρίστηκα αντισυλλογικός γιατί η οργάνωση κοστίζει 50ευρώ  ::   ::   ::

----------


## m0bius

Αμά θέλει ο winner μπορεί να μου στείλει το schema της βάσης και τα php να δω αν μπορώ να συνεισφέρω. Απλά επειδή αυτή τη στιγμή έχει πήξει το κεφάλι μου με PHP και βάσεις λόγω πτυχιακής δεν θα είναι πρώτη μου προτεραιότητα όπως ανέφερα και στον Mick_Flemm πρίν.

----------


## Winner

Κι εγώ εξεταστική, άστα να πάνε.

Στήνουμε με τον paravoid ένα SVN για το development του project.
Σύντομα θα μπορώ να σας πω περισσότερα.

----------


## m0bius

Όταν με το καλό το στήσετε θα το κοιτάξω  ::  Καλά ξεμπερδέματα  ::

----------


## Mick Flemm

Μπράβο παιδιά, είδα το project και είναι σε πολύ καλό δρόμο, θα μπορούσατε να δώσετε τον κώδικα και το schema της db στο forum ?

----------


## Winner

> Μπράβο παιδιά, είδα το project και είναι σε πολύ καλό δρόμο, θα μπορούσατε να δώσετε τον κώδικα και το schema της db στο forum ?


Mick αν δεις δυο post παραπάνω έχω πει πως θα δώσουμε access σε SVN.
Επίσης, διάβασα το απογοητευτικό σου post. Νομίζω πως σου είχα αναφέρει πως είχε ξεκινήσει το συγκεκριμένο project. Πιστεύω στο να δεις πιο ήρεμα τα πράγματα και να αλλάξεις την απόφασή σου.

Εν πάσει περιπτώση, να πω πως ετοιμάζουμε το project (με ονομασία *WiND* - Wireless Node Database) κάτω από GPL license για να είμαστε όλοι ευχαριστημένοι (εμείς και πιθανότατα άλλες κοινότητες). Αν έχει κάποιος να προτείνει κάτι καλύτερο όσον αφορά το license, προσωπικά θα τον ακούσω με ευχαρίστηση μιας και το θέμα του licensing με έχει παιδέψει αρκετά τον τελευταίο καιρό.

----------

