Would you get fired if you used VARCHAR instead of DATETIME to store dates?
-
What would happen in your country?
VARCHAR for everyone
When to use VARCHAR and DATE/DATETIME on Stackoverflow
-
I love when my reports all show start/end dates as:
https://www.youtube.com/watch?v=otCpCn0l4Wo
-
You need to do that if you use SQLite.
-
Okay sorry I didn't specify what RDBMS it was.
It's Oracle y'all !.
-
I love this.
-
What does that have to do with country? It depends on the company, seniority, etc.
I myself would be very very dissapoint if I saw someone try that shit on my watch.
-
I'm sorry if I sounded like over generalising.
It's only my personal experience that I've worked for three different companies in this country and none of them seemed to have any issue at all with VARCHAR type date columns.
-
Tell them to stop doing that, please.
It's stupid.
-
I don't know if I'd get fired, but people would certainly start assuming I'm incompetent.
-
Tell them to stop doing that, please.
It's stupid.
Shut up, fatass!
I always wanted to do this
-
I would probably get told not to do it after the first time, same after the next few. If I kept it up and it was causing easily preventable issues, I could probably expect to either not be allowed to do database design, or let go. Depending on company size...
-
My coworkers would not even look twice if this were a thing.
If I saw other people doing it, though, there would be words.
-
I would hope I would get fired, or at least reprimanded, for something that boneheaded. Sadly, there have been too many jobs where that would have been the least of the s going on in the database (assuming it was actually a database at all, and not an Excel spreadsheet, a CSV file, or bunch of post-it notes on the boss's desk). Unless it were SQLite, of course, then you don't have much choice, unless you want to be pigheadedly stupid and use, I dunno, an integer maybe? Meh, I've seen worse...
-
unless you want to be pigheadedly stupid and use, I dunno, an integer maybe?
Isn't that what most DateTime implementations use internally?
That should be good enough for storage and sorting, shouldn't it?
Or am I missing something?
-
Well, yes, that's true. The problem is the lack of typing, more than anything, as there's a much greater chance of that way - at least with a VARCHAR, you can see that it looks like it might be a date.
And before anyone gets snarky about typing in languages, I would like to mention that a) databases are their own thing, since specifying the domains (types) of attributes is necessary for normalization, and b) values in Lisp are typed, it's the symbols that name them which aren't, same as in Python or any of several other languages I can name.
Filed Under: I'm not sure why I felt the need to say that last part.
-
Wouldn't pass code review. You'd get weird looks, but not fired unless you did it a LOT or tried to push it through code review anyway. Even then it'd be multiple "let's talked" before firing was put on the table as an option.
But this is really company-specific. Hard to give any general answer. Fart Master G might get fired due to this because people really hate his farting, but it's hard to fire for that.
-
Isn't that what most DateTime implementations use internally?
Only in shitty RDBMS. Non-shitty ones need to store things like "birthdates" and "timezones", which the Unix timestamp "format" is ass for.
-
Wouldn't pass code review. You'd get weird looks, but not fired unless you did it a LOT or tried to push it through code review anyway.
Just imagine this wonderful clusterfuck of application code designed to support these half-assed date strings.
-
Only in shitty RDBMS
From SQL Server Books Online : Values with the DATETIME data type are stored internally by Microsoft SQL Server as two 4-byte integers
-
Ok?
Is this like a novelty account where you post quotes from SQL Server Books Online that have nothing to do with anything whenever someone mentions databases, or... what is this?
-
From SQL Server Books Online : Values with the DATETIME data type are stored internally by Microsoft SQL Server as two 4-byte integers
And strings are stored as a series of numbers. What exactly is your point?
-
and use, I dunno, an integer maybe?
Isn't that what most DateTime implementations use internally?
That should be good enough for storage and sorting, shouldn't it?
Or am I missing something?
Only in shitty RDBMS
Reading comprehension problem ? Again !
-
TIL 2 4-byte integers == an integer.
I guess.
Because that's the only explanation other than TimeBandit is a dumbshit moron who can't read what an ass.
-
Because that's the only explanation other than TimeBandit is a dumbshit moron who can't read what an ass.
no, there's another explanation, but you won't like it.
-
Tell them to stop doing that, please.
It's stupid.
Depends on the situation, I guess... there are cases when storing numeric (in the [0-9]+ sense) as strings is justified, maybe there are some for the dates.
Can't think of any though.
-
there are cases when storing numeric (in the [0-9]+ sense) as strings is justified,
What are the cases?
-
Phone numbers, for example, or SSNs. Basically anything you'll never need to use as a number (do math on it, etc), and all you get from storing it as one is a headache when your displaying code eats your leading zeroes or rounds it.
Trust me, it's not fun to deal with a situation where an XXXX.YY identifier (four numbers-dot-two numbers) gets stored as DECIMAL, and you need to fuck around not to make the dot turn into a comma, or have the formatting code insert thousands separators into it, or getting
1234.3
from some procedure and trying to figure out if it was1234.03
or1234.30
.
-
ass
Why are you so obsessed with man-ass? You're getting ready to come out to us, aren't you? It's OK blakey, you are in a safe place.
-
This.
We had a request recently to add some fields to our application which stored 9 numeric IDs - and the requirement was to store them in the database asNUMBER
. Our application formats numbers as per the users regional settings so - for the UK - 123456789 is shown as 123,456,789. It turned out the project needed them displayed like 123456789 so we ended up redefining them as strings and changing the fields toVARCHAR(9)
.
-
So instead of fixing your application and telling it how to format numbers in more than one way -- which might be useful in multiple locations in an application -- your answer was a schema change from numeric to non-numeric?
This is like saying, "We were building a car, but it turns out that Tom we only had waterproof paint. So we made a 4-wheeled boat instead."
-
We have hundreds of number fields, all of which get formatted the same until these 7 fields got added and needed treating as strings.
Storing it as a string and treating it as a string involves zero special snowflake code, versus storing it as a number and making sure it's treated as a number everywhere.This is like saying
It isn't.
-
We had a request recently to add some fields to our application which stored 9 numeric IDs - and the requirement was to store them in the database as NUMBER.
Your requirements process is operating at the wrong level.
-
Phone numbers, for example, or SSNs. Basically anything you'll never need to use as a number (do math on it, etc)
This cannot be emphasized enough. Just because a string can contain only digits, that doesn't make it a number. SSNs are a classic example of people mistakenly storing them as numbers. ZIP codes are another. If you store those as numbers, there's a good chance that I will break your system (they both start with 0 for me).
-
I know. Everyone on the technical side of my current team knows.
The "requirements" "process" is something that's fucked up before it gets to my side of our team. It'd be worth an entire essay in the Lounge except I'm not sure I can keep it sufficiently anonymised and still retain enough of the context and factor.I'm escaping this team in a week(ish) to another team which not only deals with a modern application but that gets the rest of the process largely correct too.
-
ZIP codes ... start with 0 for me
Clearly, you just live in the wrong part of the country.
-
@Dragnslcr said:
ZIP codes ... start with 0 for me
Clearly, you just live in the wrong part of the country.
I prefer to think of it as the right part of the country. The upper-right part, that is.
-
Fart Master G might get fired due to this because people really hate his farting, but it's hard to fire for that.
I dunno, Mythbusters demonstrated that for such emissions, a lighter or a match works pretty well.
-
Without even reading the thread, I somehow know it was from @ascendent
Dude, have you thought of defecting to a more tolerable country, like The Democratic Republic of Congo, or that miles-wide garbage island floating through international waters?
-
After all the belgium I've seen in tech, I think it's pretty much impossible for someone to get fired. Just don't steal anything, don't punch your boss on his face, avoid any serious crime and you're good.
Maybe if you do something that result in a direct loss of a significant amount of money or a large customer.
-
Hmm I think that could be reasonable but what about those arguments that the database should be the last line of data sanity defence?
That the database should make sure you can't put 9 random characters like "ILOVEPHP!" into the supposed "number" column?
-
Why is there no decimal-digit-string type? Databases could hold twice as many of them in the same amount of space just by using binary coded decimals instead of ASCII.
-
@Lorne_Kates said:
Without even reading the thread, I somehow know it was from @ascendent
Dude, have you thought of defecting to a more tolerable country, like The Democratic Republic of Congo, or that miles-wide garbage island floating through international waters?
-
And you know, bonus WTF
Oh btw, did I tell you that we use SELECT MAX(ID) +1 to get the next sequence value?
-
Oh btw, did I tell you that we use SELECT MAX(ID) +1 to get the next sequence value?
That strategy scales just fine to support a single user doing single-row inserts. What? You want multiple concurrent seats? That'll cost extra.
-
but what about those arguments that the database should be the last line of data sanity defence?
Doesn't Oracle have some sort of regex validation? Or hell, even something like
NOT LIKE '%[^0-9]%'
should work in this case...
-
or getting 1234.3 from some procedure and trying to figure out if it was 1234.03 or 1234.30.
Apparently that isn't a thing. Or not a thing to be overly concerned about.
Apparently. According to at least two people here.
-
This seems like a very very raw WTF whatever that is supposed to mean. If someone around here is using varchar columns for date, he would be caught and no one will stop giving him shit about it as long as he works there.
varchar guy : Hey guys good morning
Normal guy : Oh hey good morn...After varchar guy walks away
Normal guy to the janitor : There goes the fucking cunt who tried to store dates in varchar, fucking dipshit, stay clear of him janitorman.
Janitor : Uh okay thanks for the heads up i guess
-
I would hope as computer scientists that we would all know that 1234.3, 1234.30, and 1234.300 are all the same number as long as they're all in the same base.
Unfortunately, due to some idiotic decision in the past, 01234.3 is an octal number due to the leading 0.
Filed under: A leading zero to denote octal is just stupid
-
"1234.3 = 1234.03" occurs if the routine got "1234" and "3" from two separate fields, as numbers, and concatenated them as strings with a decimal point in between.
"routine is truncating trailing zeros from decimal" is a slightly different problem, which doesn't change the value of the number, just the presentation of it.
-