Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I realize this idea might seem really foreign but I started thinking about this a bit back.

Far as web sites go, at least in my experience, there is far more time spent retyping things to a String than the other way around. For instance:

Say you have a user model:

user 
  int UserId

And I wanted to log the user in:

View  -> string to int -> controller -> int to dbInt -> database -> dbint to int -> controller -> int to string -> View

At no point in that whole exchange did I need an int. The one typing I did need was with the database, but that's just kind of expected.

Now if I wanted to show a list of users based on a group id, the same thing happens except that UserId conversion happens for how many there are on the list and in the end it will just be represented as a string in the UI.

Now I understand that a string might be larger memory wise than some types (bool for example) but is this more costly than all the typing that happens?

Could it be more productive to only type when needed (Validating a number, date, ect) and just leave them as strings for the most part?

share|improve this question
1  
what programming language are you using? –  GSto Jan 9 '12 at 21:34
    
What do you mean about the cost of typing? There's runtime performance implications in transforming a string to an integer to a string, but they aren't directly comparable with the storage savings of storing as an integer rather than a string. –  David Thornley Jan 9 '12 at 21:43
add comment

3 Answers

There is no reason that you can't store every thing as string (db and presentation layers), particularly if that makes sense for your application. The only reason to resort to specific types is to enforce data integrity (eg date types, like you suggested in your post) or maybe because performance is required (eg using ints as id fields in database tables to join on as they should be faster). Performance should not be an issue unless you have a very high concurrency or slow/low powered hardware.

share|improve this answer
    
I was going to say something to this effect, enforcing data integrity is huge, having to manually verify that data in a string is the correct type every time you need to debug is a huge and unnecessary waste of time. –  Ryathal Jan 9 '12 at 21:54
add comment

In addition to what Justin Cave wrote, let me add that you do not have to go as far as dates to see the problem: if plain numbers were represented in string format in databases, 1111 would be sorted between 100 and 122. That would not work, would it? So, in order for the database to properly sort the number-strings, it would have to convert them to actual numbers first. Well, it turns out it saves everyone time, effort and headache if they are simply stored as numbers.

share|improve this answer
add comment

Memory usage is way down the list of the benefits of data typing.

Take dates for example. If you are accepting a date in a form field, you likely want to be at least somewhat permissive about accepting the data in whatever format the user wants to enter it (i.e. 7/1/77 or 7-1-1977 or 7-77 if you're designing for an American audience might all be acceptable ways to represent July 1, 1977). If you don't convert that to a DATE data type, however, then every piece of code that touches the string has to know what format it's in. They all have to know how to manipulate that particular string representation if, for example, you need to sort by the date or convert it to a preferred display format. You could choose some sort of canonical string representation and convert the input string to the canonical representation and then code everything else to assume that the data is in the canonical representation before manipulation. Of course, then every application might choose a different canonical representation so various libraries may work differently on different projects. You are much better off simply converting the string to a date early in the process because then everything can simply operate on a date-- you can sort on the date, you can convert the date to a different string representation, you can extract components of the date, etc. in a simple, straightforward, and clear fashion.

Of course, you could design the user interface to prevent users from typing in free-form dates by requiring that, for example, they always use a date picker or they use separate fields for each date component (i.e. picking "July" from a drop-down list). That mitigates some of the issues from the prior paragraph but it ties decisions made in the view layer about how best to collect data to decisions in other layers about how to present the data in the future. And you're still stuck writing code that converts the various components to various other formats in order to sort, writing functions that do things like determine whether a date is a holiday or how to add 30 days to a particular date without using any date libraries.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.