|
Our company uses Oracle and SQL Server, both from C#.
SQL Server support isn't really a requirement (now), but I was pretty sure it would work as it's SQL in it's simplest form (although apparently there is no 'simple' form of SQL)...
Anyway, screw SQL Server support.
|
|
|
|
|
It'll get even funnier when you realize that even when the SQL is completely compatible, the results may not be.
For example: Oracle doesn't have an empty string.
|
|
|
|
|
Jörgen Andersson wrote: For example: Oracle doesn't have an empty string. Or a bit/bool data type...
Jörgen Andersson wrote: It'll get even funnier I'm not laughing
|
|
|
|
|
Jörgen Andersson wrote: Oracle doesn't have
A GUID type.
In some databases a one-byte integer is signed; in others it's unsigned.
|
|
|
|
|
PIEBALDconsult wrote: A GUID type
Syntactic sugar. Use myguid RAW(16) default SYS_GUID()
Or rather, don't use them at all.
The only serious place where GUIDs have the edge over sequences is on distributed systems.
|
|
|
|
|
Jörgen Andersson wrote: is on distributed systems
They're all distributed systems.
|
|
|
|
|
Jörgen Andersson wrote: why do you need to support more than one database?
Because one features premium pay and the other features ubiquitous jobs?
|
|
|
|
|
If the minor differences between databases already make you cry, then please stay away from anything that has to do with browsers.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
CDP1802 wrote: stay away from anything that has to do with browsers As a full-stack web developer that'll be difficult.
And yes it makes me cry and gives me nightmares, why can't we all just get along?
Sometimes I want to go back to my safe and simple WinForms, now that's good technology
|
|
|
|
|
Very true, but some people think it just does not feel right if it is not as complicated and convoluted as possible. Browsers, CSS, JavaScript HTMl, throw them all away and build a native client where ever possible. Then you will certainly have a better UI.
As for the databases, perhaps you should use a ORM as abstraction. Then you can be fairly independent of the actual database that is used. At the price (as someone already noted) that you will do everybody a favor and not do any more presentation layer stuff in the data layer.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
CDP1802 wrote: perhaps you should use a ORM as abstraction This is the 'dynamic everything should be possible' kind of code. In my experience ORM's don't handle that very well... We've tried some solutions, but ultimately decided to build our own solution, which is what I'm now doing
CDP1802 wrote: you will do everybody a favor and not do any more presentation layer stuff in the data layer I'm not
|
|
|
|
|
Sander Rossel wrote: This is the 'dynamic everything should be possible' kind of code.
Good luck. Everybody and his dog must give it a try, I guess.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
CDP1802 wrote: perhaps you should use a ORM as abstraction
Works fine for CRUD, but...
|
|
|
|
|
Yes, and most things where CRUD does not work are the direct road to hell. I have seen many failed 'dynamic' SQL thingies and every time the 'creators' finally noticed that they could not swim when they were in the middle of the ocean.
I'm patching up another interesting creation right now. Each table in the database has more triggers than an average piece of sh.t . Not just 'normal' triggers, if there is such a thing. Those triggers contain real application logic and also try to do everything at once, triggering even more triggers. The whole avalanche is stopped by setting special columns in the data rows.
Now, I need to change a value in a primary key of one row, which usually means deleting and then inserting the row with its new key. If I do that, the wrong triggers will start triggering and everything goes to hell (GOTO is very bad).
Our geniuses did an update on the data row with the new key and then the (hopefully) right triggers will take over. The problem is that I really use an ORM and updating on a new primary key value will not cause an error, but also update nothing.
There hopefully is a special place in hell reserved for those people.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
CDP1802 wrote: more triggers than an average piece of sh.t
I think you mean "more triggers than Texas".
|
|
|
|
|
I used to live there. Don't mess with Texas
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Saw a t-shirt once: "Don't mess with Texas, it's not nice to pick on retards"
A very brave fellow I might add.
|
|
|
|
|
Anyone using triggers for anything else than logging, or with any recursion whatsoever, should get publically flogged.
Just a personal opinion.
|
|
|
|
|
Same here. I built a 'don't use this for anything else than this one purpose' update method and it finally seems to work - except that now something else is not updated correctly. Turned out to be the same thing our heroes pulled off on another table. And of course more extra hours for finding this.
Now it's very late, I still have a one and a half hour trip home, will not get much to eat tonight unless I pick up some greasy junk along the way and would I love to strangle that idiot that invented the technique of updating primary keys and enforcing this nonsense with countless triggers.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
If there's anything worse than nested triggers, it has to be people fiddling with primary keys.
You have my sympathies, and I wish your company would pay you for a decent restaurant.
My old job actually had that as a rule, if you were forced to work past eight o'clock the dinner was paid for. Within reason.
|
|
|
|
|
Jörgen Andersson wrote: pay you for a decent restaurant.
Are you joking? They will cry how long it took me to find and correct it. They actually tried to tell us that we do and always have produced excellent quality - as a company guideline. If they say so, then it must be true and it must somehow be our fault when something does not go according to plan.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
CDP1802 wrote: perhaps you should use a ORM as abstraction
Frack no! That just makes things worse!
|
|
|
|
|
CDP1802 wrote: If the minor differences between databases already make you cry, then please stay away from anything that has to do with browsers.
But it's the minor differences that cause the subtle bugs which take the most time and require the greatest pulling of hair to resolve.
|
|
|
|
|
Ok, then it should be the probabilty of a subtle bug, weighted by its severity.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Don't forget to also weight according to the severity of the motivational floggings that are part of the debugging process.
|
|
|
|