Sophia Green wrote:@Christian Pflugradt Okay, but shouldn't radio buttons be stored as tinyints(1) in the database? Like a boolean
You aren't storing the state of one radio button in the database but you set a
String field depending on which radio button is selected:
You are storing this String variable in the database so you will need a varchar field.
This does not mean that this is the best solution. You have multiple choices here.
- You could store each individual radio button state as a tinyint in your table, that means you have one tinyint column for each radio button in your mask
- You can store the state of your radio button group in one int field
- You can store the state of your radio button group in one String field
The first option, storing each radio button in one column is not a way I would recommend here because they are all part of a group. You cannot select both "Deluxe" and "Suite", it'll be exactly one of the five room types available. It won't make sense to store them separately if you have to read and evaluate them all at the same time.
The disadvantage of the second option, using numbers instead of Strings, would be that no one knows what a 3 in that field could mean - perhaps it's equivalent to "Deluxe", who knows?
You could either create a second table that keeps a ROOM_ID and a ROOM_DESCRIPTION for instance to tell everyone that ROOM_ID 3 means "Deluxe" and ROOM_ID 2 means "Suite". That may be too much depending on the size of your database model and content or it may be not. I personally prefer this version if I can expect thousands of entries in your booking table. With a JOIN-statement you can easily get the room description for any row in your table and a number will require less space than a String. Even more important, a database-side mapping would avoid any irritating writing mistakes in the field. What if some rows are inserted that contain "Delux" instead of "Deluxe" because of a writing mistake in another
Java class or because a Third Party company with an interface to your database will send incorrect data? This will probably lead to incorrect behaviour in your application and if any other processes than your application are involved you have no way to guarantee that the field will always be set correctly.
To get your (Java) version working, which is perfectly fine for a small application in my opinion, you need to change the columns in your table declaration as follows.
varchar(20) is only a suggestion, obviously it'll depend as how large the Strings can be that you want to store in these fields.