Varchar2 als Primary Key

Status
Niet open voor verdere reacties.

Quindoo

Gebruiker
Lid geworden
27 mei 2009
Berichten
52
Beste Helpmij,

Ik ben bezig met een project voor school en ik ben bezig met een ASP.NET website te maken die verbonden is met een ORACLE database. Nu loop ik tegen een klein probleem aan, namelijk het volgende:

Ik heb een TABLE waarin een VARCHAR2 als PRIMARY KEY ingesteld staat.

Maar elke keer als ik nu een 'ROW' toe wil voegen, dan vult hij de PRIMARY KEY automatisch in en wordt dan automatisch een nummer. Maar dit wil ik juist niet..

Het gaat namelijk over een tabel die bedoeld is voor een MEDEWERKER entiteit waarin ik de gebruikersnaam als unique wil hebben, maar hij blijft als nummer staan, terwijl ik toch aangeef dat het een tekst moet zijn..

Ik neem aan dat dit wel mogelijk moet zijn, maar moet dat via een omweg of zit er iets niet helemaal goed dat het eigenlijk wel moet werken? Of heb ik een kleine instelling over het hoofd gezien?

Ik werk met: Visual Studio 2008, Oracle Express Edition 10g, ASP.NET, C#

Ik hoop zo spoedig mogelijk van u te horen.

Met vriendelijke groet,
Quindoo
 
Een ID is altijd een getal, je moet een extra ID veld opnemen en die als primary gebruiken, en dan een veld maken voor de gebruikersnaam. Als je wilt dat een gebruikersnaam niet meer dan 1x voor mag komen, dan moet je er een UNIQUE CONSTRAINT op zetten.

Volgensmij kan het niet dat je een varchar als primary neemt, en als het kan is het af te raden want dat maakt je database een stuk trager en een stuk groter, en het maakt het wijzigen van iemands gebruikersnaam een pain-in-the-ass.

IDs zijn altijd dingen die geen betekenis hebben buiten de database.
 
Een ID is altijd een getal, je moet een extra ID veld opnemen en die als primary gebruiken, en dan een veld maken voor de gebruikersnaam. Als je wilt dat een gebruikersnaam niet meer dan 1x voor mag komen, dan moet je er een UNIQUE CONSTRAINT op zetten.

Volgensmij kan het niet dat je een varchar als primary neemt, en als het kan is het af te raden want dat maakt je database een stuk trager en een stuk groter, en het maakt het wijzigen van iemands gebruikersnaam een pain-in-the-ass.

IDs zijn altijd dingen die geen betekenis hebben buiten de database.

Oke, maar ik had ook geen ID gemaakt voor deze entiteit, alleen maar een PK, tenzij jij hiermee hetzelfde bedoelt.

Maar kortom, ik moet dus:

1 extra attribuut toevoegen - ID, nummer maken i.p.v. varchar2
2 een primary key van de ID maken
3 de attribuut gebruikersnaam kan varchar2 blijven, maar hier moet een unique constraint voor gemaakt worden.

en dan zou het dus moeten werken?

Edit: Het werkt nou trouwens, hopelijk krijg ik er geen minpunten van omdat het nu anders dan mijn uitwerking is, maarja, het werkt wel in ieder geval :D

Bedankt!

Ik heb de status van de vraag aangepast naar: Vraag is opgelost
 
Laatst bewerkt:
Als iemand punten aftrekt van een opdracht omdat je niet een Varchar als Primary Key gebruikt, dan moet je die persoon slaan. Dat is echt onzin.
 
Als iemand punten aftrekt van een opdracht omdat je niet een Varchar als Primary Key gebruikt, dan moet je die persoon slaan. Dat is echt onzin.

Haha, nee dat is het niet zo zeer, het gaat meer om het principe dat ik mijn project van te voren uitgewerkt heb, waaronder ook een database model. Hierin heb ik dus die varchar2 als primary key staan enz, dus dat je het eigenlijk anders maakt dan dat je zelf uitgewerkt heb is dan het eventuele probleem. Maar dat zal wel niet zo erg zijn denk, want echte programmeurs komen ook wel eens foutjes tegen in hun ontwerpen die aangepast moeten worden.
 
Jazeker, technische ontwerpen bevatten ook weleens foutjes. Je kunt het beste gewoon aangeven dat je een kleine wijziging hebt gemaakt wegens een technische beperking of een uitwerkingsfout.

Programmeren is lastig werk en fouten kom je altijd tegen. Gewoon verbeteren; uiteindelijk gaat het (hoop ik toch) om dat het eindproduct aan de eisen voldoet en niet dat het eindproduct perfect gebouwd is naar een fout schema en dus niet goed werkt.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan