|
I reckon I can handle step 1 and 3. Could you please expand on step 2.
|
|
|
|
|
Step 2 is to send me money 
|
|
|
|
|
At least SQL Server does have a bit data type that can be set to 1 or 0 which is closer to boolean.
No matter where you go, there you are...~?~
|
|
|
|
|
Sander, we're all professionals here. No need to point out the obvious about it not being an ISO standard. However, it doesn't mean one shouldn't follow common best practices. I can list a handful of reasons why doing what they did is a bad idea for booleans, and any DBA worth his/her weight could too. I choose not to state the obvious however, unless it's asked.
Btw, the sky is blue. 
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: No need to point out the obvious about it not being an ISO standard
That wasn't so obvious to me.
I never knew until I needed to use Oracle instead of SQL Server.
Jeremy Falcon wrote: Btw, the sky is blue.
I'm looking outside and it looks more like black to me. Then again, it is 21:30 o' clock.
Were I in the Westland it would be yellowish (due to the many greenhouses that seem to set the sky alight).
I've been in cities where the color was grey.
Don't assume that whatever is obvious to you is obvious to others as well.
Or is that obvious advice? 
|
|
|
|
|
Sander Rossel wrote: Or is that obvious advice?
Sure, but you assumed I had no idea what I was talking about and missed the point. Let me use an example, you say "hey" and then I say a 10 page essay on the origins of "hey"... because I just can't wait to tell someone what I know and/or read. Whether or not you know this already doesn't matter, I just want to say it.
That's the IT way man. I never asked or even pretended to not-know, you just assumed it when "correcting" or informing me. You can say that wasn't the premise and the idea is to inform the world at large, but I believe if that were the case you would've said so. Computer people just love assuming people are clueless man, lack of social skills.
Sander Rossel wrote: Were I in the Westland it would be yellowish (due to the many greenhouses that seem to set the sky alight).
Jeremy Falcon
|
|
|
|
|
|
Sander Rossel wrote: Sorry man, you seem quite bothered by my little ISO comment.
I suppose a wee bit. Just a bit too used to dealing with people in this industry trying to "show off knowledge" without regards to the actual conversation ya know. Anyway, I'll shut up now.
Sander Rossel wrote: I was just trying to cut the SAP people a little slack, but you are merciless!
No comment. 
Sander Rossel wrote: Anyway, to assume makes and ass of u and me
Maybe, but I'd rather be an ass than a SAP developer. 
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: people in this industry trying to "show off knowledge"
I'll show off with my books and articles, no lounge post can tip that
I really only mentioned that just to show off.
Jeremy Falcon wrote: Maybe, but I'd rather be an ass than a SAP developer.
What's the difference? 
|
|
|
|
|
Sander Rossel wrote: I really only mentioned that just to show off.
Touché!
Jeremy Falcon
|
|
|
|
|
Sander Rossel wrote: Oracle, for example, doesn't have a boolean data type
Also, a lot of RDBMSs don't have a boolean type, but come on, everyone knows to use an integral value for boolean logic in that case. I could list the reasons why, but after 20 years of arguing online with people that love to argue because they mistake that for being "smart", I simply do not care anymore. I'd rather spend my time more wisely then argue with people with no experience (not saying you, you're smart just well you know... if you've hung around coders you know what I mean).
But, I'll give a hint why anyone worth their weight DBA wise wouldn't use a text field for booleans... code pages / character sets / insert whatever mapping here, not every RDBMSs can restrict case and if so its less performant, wasted space and memory for storage... and that's just three without having to think about it. Y/N as text simply means it was rookies. I could go on and on and on, but I no longer have the desire to these days. It just simply amazes me something so bad could make so much money, that doesn't mean I need a lesson on something about databases that I already know.
Jeremy Falcon
|
|
|
|
|
This is a warning.
If you are currently happy with your life do not continue reading.
I cannot guarantee you will ever be happy, find love, see beauty or sleep at night again after reading this.
So, don't say I didn't warn you.
One shop I worked at, that used SQL Server 2005 and up with VB.NET 2.0 and up, did not use the BIT data type, nor did they use a numeric type with 0 and 1.
Instead, they used the MBoolean, M being the first letter of the company name.
The MBoolean was a CHAR(1). Now you might expect it to be Y or N.
It wasn't.
It could actually have the values J and N, from the Dutch Ja (yes) and Nee (no).
The worst part was that they often didn't even bother to cast J/N to a regular boolean (not even in .NET), the code was littered with If something = "J" Then...
Because doing things in Dutch is so much easier when finding help on the internet.
Not even the Dutch people understood the J/N boolean
The reason for the J/N had something to do with Clipper, Visual Basic (pre-.NET) and dBase all handling booleans differently.
|
|
|
|
|
Sander Rossel wrote: So, don't say I didn't warn you.
And yet, I read it.... 
Maybe they could get a job at SAP? 
Jeremy Falcon
|
|
|
|
|
Actually, a byte for a character and a bit are frequently implemented the same: takes one bit of the eight for the value and ignores the other seven. An int would be four bytes; short int could be as small as two. So just about anyway you cut it, Y/N isn't that bad of choice. It is even self documenting!
|
|
|
|
|
Jeremy Falcon wrote: From this one table alone I can see 3 problems at least... archaic naming convention, using text fields for boolean logic, and not using an ENUM field or lookup table where appropriate
archaic naming convention: it amazes me people see another's naming/coding style and label that as bad/problem, it's not an issue - what next, pick on people who have different skin color?
using text fields for boolean: as others pointed out bool is not ISO, so not portable. SAP can use different underlying databases, and supports older DB versions of even those vendors that have those features.
and not using an ENUM field or lookup table: well this is just a combination of the above two points.
So no, your arguments that their code is bad is just simply 100% wrong.
And so you think could do it better: will it work when rolled out to thousands of live enterprise sites, some of which have older systems/databases... THIS is why SAP make so much money (and they also don't employ bragging know-it-all smart asses like yourself because you don't get it.)
Sin tack ear lol
Pressing the any key may be continuate
|
|
|
|
|
Try your pretty little online argument crap with someone less experienced and stop wasting my time. It may work on those that know no better.
And while we are at it, you use too many commas. What's next, you're a child killer?
Jeremy Falcon
|
|
|
|
|
LOL. Just keep on believing that.
SAP is making billions, you're not!
Sin tack ear lol
Pressing the any key may be continuate
|
|
|
|
|
And neither are you. So you just invalidated your own post as well.
Jeremy Falcon
|
|
|
|
|
Add PeopleSoft to that list.
To be fair, both companies are trying to build an application that streamlines business. The only problem is that every business has different thoughts on how things should be done. SAP is German over-engineered and removes a lot of flexibility from the user side of things to get things done quickly, especially from a user standpoint. Accountants love it though because it makes their job so much easier.
|
|
|
|
|
SAP gets into a company through the management board (CEO/CIO). Non technical people worried about their seat in the company - not the company itself. Their goal is to implement a system that will work - they won't take riscs with new IT companies/technologies. If the projects fails they loose their pretty seat in the company... With SAP they cannot go wrong. It'll work eventually, slow & expensive, but it'll work and they'll keep their seat.
After the implementation the saying is that everything works great, because nobody has the guts to admit that they spend X miliions for a piece of crap..
|
|
|
|
|
You sir, hit the nail on the head.
Jeremy Falcon
|
|
|
|
|
So to sum it all up it sounds like we have the perception that exorbitant cost of product should equal better coding standards or at least an upgrade to better technology. What's new?
I am curious about one aspect though... there was mention of poor referential integrity. Are you saying that there is actually misshapen data like, for instance, orphaned records or data points stored in the wrong fields or invalid values (i.e. an invalid enum value)?
That would be more alarming.
|
|
|
|
|
When I was a lot newer to programming and databases, I once wrote an application that maintained the referential integrity through the code. If I knew then what I know now
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
I unfortunately work with a legacy system that was written without FKs. The amount of crap data in this DB is enough to make angels cry. This is why I was curious.
It's the classic thinking that you only need to write a DB for the front end's needs without considering that other systems may one day interact with it with their own idiosyncrasies (forget about devs going in and mussing things up directly in the tables).
|
|
|
|
|
Ed Bouras wrote: So to sum it all up it sounds like we have the perception that exorbitant cost of product should equal better coding standards or at least an upgrade to better technology. What's new?
Touché!
Ed Bouras wrote: I am curious about one aspect though... there was mention of poor referential integrity. Are you saying that there is actually misshapen data like, for instance, orphaned records or data points stored in the wrong fields or invalid values (i.e. an invalid enum value)?
None that I've noticed yet. So I assume (hope) SAP helps enforce it, but there are no such foreign keys in the DB to help enforce it.
Ed Bouras wrote: That would be more alarming.
Finally, someone with experience talking. You're correct. Seeing the lack of foreign keys was what started this whole jaw dropping thing actually. It just went from there.
Jeremy Falcon
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
