Brauche ein wenig Feedback zu meinem Datenbankentwurf, ziemlich einfach

Question

Ich werde Unternehmen die Möglichkeit geben, sich auf meiner Website zu registrieren und Stellenanzeigen zu erstellen.

Ich gehe das Problem derzeit an, indem ich eine Firmentabelle mit den Feldern Name, Logo und Passwort erstelle. Wenn sich dann eine Person anmeldet, kann sie sagen: "Ich gehöre zu Unternehmen X"; an diesem Punkt verlange ich das Passwort, das der Erstanmelder eingegeben hat. Wenn sie/er das richtige Kennwort eingibt, erhält sie/er die Erlaubnis, Stellenanzeigen im Namen des Unternehmens zu erstellen.

Warum ich das so mache: Wenn ich alles in die Tabelle "Unternehmen" packen würde, müsste jeder neue Benutzer ein Konto anlegen, und ich hätte redundante Informationen, Firmenname, Logo usw.

Und wenn ich auf ein Passwort verzichte, kann jeder ein Stellenangebot unter dem Namen eines Unternehmens veröffentlichen, und das ist einfach falsch.

Möchten Sie etwas dazu sagen? Mache ich etwas falsch? Wie würde Sie es tun?

Answer 1

Ich würde "Jobanfragen" wie Freundschaftsanfragen bei Facebook machen, und wenn der Nutzer wirklich in diesem Unternehmen arbeitet, muss sich der Unternehmensleiter nur anmelden und es bestätigen.

Answer 2

Datenbank-Normalisierung.

Erstellen Sie eine separate Tabelle Benutzer und Firmen. Kann ein Benutzer für mehrere Unternehmen buchen? Wenn ja, benötigen Sie eine Beziehung von vielen zu vielen (was eine dritte Tabelle erfordert, um die Beziehungen im Auge zu behalten). Andernfalls sollte eine Eins-zu-Viel-Beziehung funktionieren.

Answer 3

Sie sollten zwei Tabellen erstellen:

Company:
 - id
 - logo
 ( - name, etc )

User
 - id
 - companyId (foreign key to Company.id )
 - password
 ( - username, etc. )

Auf diese Weise ist ein Benutzer ein Kind eines Unternehmens, das durch companyId identifiziert wird. Wenn sich nun ein Benutzer anmeldet, können Sie feststellen, zu welchem Unternehmen er/sie gehört, indem Sie das Unternehmen finden, das der companyId entspricht. Jetzt haben Sie ein Passwort pro Benutzer und ein Unternehmen pro Benutzer.

Und wie Jimmy sagt, wenn Sie Nutzer brauchen, um an mehreren Unternehmen teilnehmen zu können, würden Sie sie bekommen:

Company
 - id
 - logo

User
 - id
 - password

Company_User
 - companyId (foreign key to Company.id )
 - userId (foreign key to User.id )

Answer 4

Meiner Meinung nach sollten Sie eine Tabelle erstellen wie

Arbeitgeber:

     eid(pk)
     logo
     Username
     Password
     profile
     etc....

JobSeekers:

    jid(pk)
    Username
    Password
    etc...

JobPosts:

   id(pk)
   eid(Fk to Employers.eid)
   JobTitle
   Specifications....