Limit av en INT!

Hej!

Jag behöver hjälp! När jag skapar ett table, så vill jag har en INT som är begränsad mellan 1-5, inga andra värden ska gå att skriva in?

Hur gör jag?

Edit: Använder MySQL

Verkar inte finnas nåt självklart sätt att lösa det på i MySQL.

En vild diskussion i deras eget supportforum föreslår en av två vägar vad jag kan se: Antingen använda sej av typen ENUM för det attribut det gäller, eller att ha en trigger på tabellen som kollar värdet efter varje INSERT eller UPDATE.

http://forums.mysql.com/read.php?136,152474,152474

http://www.google.se/#hl=sv&biw=1676...dff00f010147a8

En riktig fuling är ju annars att ha en FK till en uppslagstabell med godkända värden...

Det där var så fult så det tänkte jag inte ens på

Möjligheten existerar ju dock, poäng för det

Det där med uppslagstabell är väl ändå inte så fult?

typ CarType där värdena 0, 1, 2 finns för SUV, blabla, blablabla. Kan även finnas mer information där. T.ex en textuell beskrivning av vad 0, 1, 2 betyder? Gör det även lätt att införa nya typer.

Jo vi löste det med att göra en droplist i HTML så man bara kunde välja mellan 1-5. Men skumt att man inte kan begränsa en INT, för en String är ju inte problem och begränsa.

Vad är iden med att lägga begränsningen i databasen?
Visst att man skapar enklare kontroller för att dubbelkolla modellens validering, te.x genom att säga att ett fält aldrig får vara NULL eller maximalt innehålla X antal tecken.

Hur är det tänkt att det hela ska fungera?

- Användaren fyller i lite informationen i ett fält.
- informationen skickas oavkortat, utan någon validering direkt till databasen.
- Databasen kastar ett fel.
- Vad sedan, matchar du ut felen och visar informationen för användaren?

Varför inte höja abstraktionsnivån en aning och validera informationen långt innan den ens når datasen? Man kan på så vis byta databas utan att blinka, jag menar; modellen bör ju inte vara beroende av vilken databasmotor som körs under huven.

Det hela går även snabbare, eftersom ingen onödig information skickas till databasen.

snouser:

Man ska såklart göra båda. Göra det i databasen för att skydda data från andra källor än just din webapplikation/webservice. Tänk om någon klåfingrig idiot går in och gör dumma saker via t.ex Mysql workbench eller SQL Management Studio osv? Vad händer om programmet ska implementeras om, t.ex som en webservice, är det då helt garanterat att det sköts buggfritt och att fel data aldrig försöks skjutas in i databasen?

Finns alldeles för många klåfingriga idioter.

Utöver det borde man också validera input i applikationen för att kunna ge schysst felmeddelanden osv.

Ungefär som "varför använda foreign keys/referentiell integritet".

Höja abstraktionsnivån? Skulle säga att det snarare är att sänka säkerheten för ditt programs validitet...

Kul med lite olika idér, ska nämnas att jag är ny inom denna värld och sitter och pillar för att lära mig. Men just nu testade jag att lägga upp en sida, motsvarande IMDB, där man kan skriva in "Filmnamn, Genre, Rating & Year". T.ex. med Year så kunde man skriva det som en YEAR(4), vilket innebar att det bara gick skriva in från 1901-2155 eller något sådant, alltså så skrivs det inte in databasen om man skriver 3040. Spontant tyckte jag då, att ratingen ska gå från 1-5 och att det borde finnas en enkelt sätt att begränsa INT.

Absolut, det som förbyllade mig var att ingen påpekade att TS kanske bör validera användarens data långt innan den når databasen.

Jag menar; att lägga till en liten if-sats som kontrollerar ingående data och beroende på utfall sparar informationen känns som en enklare lösning för TS.




try_to_figure_out_what_error_occurred-delen under skrivningen är i många fall jobbigare att ta hand om än första kodstycket.

Sedan så tampas man med andra problem när man försöker göra onödiga skrivförsök till databasen.
När en skrivning görs så kan ingen annan läsa, skriva eller plocka bort information från tabellen. Vilket gör att andra processer kommer att köa upp.


Vilka andra andra källor?

Ajax-requests och liknande requests gör sina requests via ett REST-API.
REST-API:et går i sin tur alltid genom modellen, var vid informationen valideras.


Jag kan inte riktigt se hur detta skulle kunna inträffa då det bara är produktionsservern som har skrivrättigheter till databasen.


Utveckla gärna det där.

Du menar te.x om vi skulle välja att använda vår desktop-applikations databas i en webbsite?


Eller är det migrering av informationen mellan de olika databaserna du pratar om?


Vad dessa personer gör med sin egen kopia av databasen är inte riktigt mitt problem.


Trevliga och läsbara fel kan du fortfarande ge användaren utifrån din lösning.

- Skriv till databasen
- Några fel?
- Ja? Fånga felet och meddela användaren att något gick fel.
- Nej? Allt gick bra


Vad dessa två saker har med varandra och göra förstår jag inte riktigt.

Modellen, precis som vyn eller användarens webbläsare ligger, enligt min mening, på en högre abstrakt nivå än te.x en databas.


Det kanske är lite tidigt att introducera MVC-modellen för dig, då jag gissar på att är relativt ny i branschen. Kortfattat så delegerar man en del av ens applikation till att prata mot någon typ av källa. Exakt vad källan är för något ska inte spela någon roll för övriga delar av applikationen.

Ungefär så här.


Exakt hur alla bilar hämtas är irrelevant för övriga delar av ens applikation.
Källan kan te.x vara Volvos hemsida eller en PostgreSQL-databas.