• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Is data validation necessary?

 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I am wondering if it is ever necessary to validate the record data. Since the application has to only allow the user to book a record (URLyBird), the only data that needs to be validated is a customer ID.

Although there is a create method (that I have implemented) in the data access interface, it is never called in my application, and so I do not think that it is necessary to write a validation engine.

In the Javadoc of the database writer class and the Data class, I say that no data validation is done - therefore, the programmer must be careful or use a validation layer at another point in the program.

Of course, I have separated my application into layers, so I would be able to to easily write a validation engine, but I would "plug" such an engine into my business logic layer. However, there are no methods in my business logic layer (except for book(), which just validates the customer ID string) that would use such a validation engine.

Therefore, I think that data validation falls under the category of extra code that will not increase my score, and I will have to assume that when Sun runs a test on my create() and update() methods, that they will use valid data.

What do you think?
 
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So long as you are 100% sure that having duplicate records in your database won't harm integrity, you should be okay.

I was paranoid, and treated the combination of business name and location as a compound primary key; I didn't let users enter another company combination which matched a combination already existing in the database in order to enforce data integrity.

I did the validation from the GUI framework though, and left the data access layer purely for data access.

J
 
Ranch Hand
Posts: 288
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In order to keep the Data class generic (if that is a goal) it is a good idea not to do any validation at this layer. As we do not have to provide any create functions the business level then there is nowhere to put this validation, unless you want to go to the trouble of creating extra methods in your facade that can never be called from the GUI and will not gan you any extra marks.

I am of the opinion that the URLyBird project (don't know enough about the others) has no primary key in any case. I'm sure the hotel owner would swiftly move his business on elsewhere if he could only advertise one room per night with the system. Is it really inconcievable that a hotel could not have two non-smoking rooms available for 4 people at the same price?
 
Cless Alvein
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

As we do not have to provide any create functions the business level then there is nowhere to put this validation, unless you want to go to the trouble of creating extra methods in your facade that can never be called from the GUI and will not gan you any extra marks.

That is exactly what I was thinking. If there is at least one other person out there that agrees with me, then I think that it will be a valid design decision that can be explained in choices.txt.

Yes, URLyBird has no primary keys in the database - the record numbers are determined by the database application at runtime. In my application, the record number is equal to the index of the record in the database - therefore it is completely independent of the record's data. Also as Mark said, it is very possible that there could be two identical rooms (same hotel, same city, same rate, etc...).

I think that I will develop a validation engine framework, but only employ it to validate the customer ID (during booking) since that is the only time when a value is being inserted into the database. I could care less if people used invalid values for the find() function since that will not harm the database, and only their search results will be affected; this works along the principle of "if garbage goes in, garbage comes out."

Once again, thank you for the replies.
 
Ranch Hand
Posts: 152
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeremy Botha:

I was paranoid, and treated the combination of business name and location as a compound primary key; I didn't let users enter another company combination which matched a combination already existing in the database in order to enforce data integrity.



Hi Jeremy,

I think that is a bad idea. A record in the urly bird database represents a ROOM. Why wouldn't a hotel owner be allowed to offer several rooms in his hotel? It could even be that a hotel has several rooms in the offering with exactly the same specs (size, smoking/non, etc).

If I were you I would reconsider this primary key, because you for sure won't gain any points by this, and chances are that it will cost you points.

For the rest: I agree fully with Mark.
[ June 29, 2007: Message edited by: rinke hoekstra ]
 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I think data validation is necessary !

A simple exmple:
You update a Record like Palace, Smallville, .... with an String-Array containing "A cool and fancy name with a length of over 64 characters....",null,....

Depending on your design you are overwriting existing data in your database!

My requirements say that we have to implement "database functionality". So if you have a relational database you define the type of every field while creating a table. (Length and type using varchar(length),date, decimal,..). So thats exactly what you have to do here.

I implemented the following validations in the database-layer:
1. Length of every field doesn't exeed the maximum size
2. "rate" is parsable to float
3. "size" is parsable to int
4. "smoking" is indirectly parsable to boolean (is element of {"y","Y","n","N"}
5. "date" is parsable to java.util.Date using "DateFormat"

Otherwise I throw a RuntimeException (like JDBC is doing also)
[ August 15, 2007: Message edited by: Romeo Kienzler ]
 
rinke hoekstra
Ranch Hand
Posts: 152
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Romeo Kienzler:
Hi,

Depending on your design you are overwriting existing data in your database!



Normally not. You normally write the elements of the String array from first to last element, so the next field would overwrite the surpluss characters of the name which is too long. You don't have to do anything about it, as long as you document this.

I wouldn't do any validation on the db package level. Of course you could do some validation on gui level, for example pop up a warning "too long fieldnames will be cut off" if field names are to long (or simply: do not allow too long names).
 
Ranch Hand
Posts: 188
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Romeo,

In a relational database you would have the different data types like int, date etc to support this validation, however it is not provided in the current database schema.

Therefore to keep the database layer generic I think you can only validate the length of each string, by adding validation for rate, size etc you are coupling the database class to the current database format, what would happen to your design if a new field was added or and different database file was used.

I would suggest you are including business logic which will limit the reuse of the database class. I would therefore recommend keeping the database layer generic and move the validation to the business layer.

Regards
Jason
 
Jeremy Botha
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by rinke hoekstra:
[QB]

Hi Jeremy,

I think that is a bad idea. A record in the urly bird database represents a ROOM. Why wouldn't a hotel owner be allowed to offer several rooms in his hotel? It could even be that a hotel has several rooms in the offering with exactly the same specs (size, smoking/non, etc).




Hi, Rinke.

I was dealing with B&S, not UrlyBird. Sorry, I should have made that more clear.

J
 
snakes are really good at eating slugs. And you wouldn't think it, but so are tiny ads:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic