|
ElectronProgrammer wrote: Grab your whip and get the guy that wrote that database. Don't let him procreate more databases like that
FTFY
|
|
|
|
|
ElectronProgrammer wrote: the guy that wrote that database If it was indeed created by a human and not dynamically created by some program
Anyway, the person responsible is probably a supplier of a supplier of my customer somewhere in the 80's, but I can't say for sure
|
|
|
|
|
Never used SQL but
Could CNY be Chinese Yuan? It's the standard forex abbreviation for it.
|
|
|
|
|
Greg Utas wrote: Could CNY be Chinese Yuan? Nope, it's actually short for CurreNcY.
Makes perfect sense if you designed that database I guess
|
|
|
|
|
Death to abbreviations. Just die!
Also, fix your elephanting spelling errors.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
And I'll bet some company tables are unique so combining them will be a challenge. I made a tidy living in the 90's attempting to normalise such horrors, never quite that big and ugly though. I wonder if the original was converted from MS Access, it is definitely an end user built database.
So quote a rate and don't offer a time frame (or even a guarantee) if you are going to try and clean it up.
PS CNY is definitely the Chinese currency.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Mycroft Holmes wrote: And I'll bet some company tables are unique so combining them will be a challenge. No doubt, luckily there's no need to combine them
Hopefully I'll never see this database again
Mycroft Holmes wrote: it is definitely an end user built database Don't think so, end users here are typically as a-technical as they come.
I think a lot of it was generated though.
The database is owned by another supplier and kept around for historical purposes, I don't think it's actively being used anymore.
Mycroft Holmes wrote: PS CNY is definitely the Chinese currency. Nope, it's short for CurreNcY
The amount in the column is usually the same as that in the regular amount column, except when the customer is not a Euro country.
This supplier doesn't do anything with China specifically.
Mycroft Holmes wrote: So quote a rate and don't offer a time frame (or even a guarantee) if you are going to try and clean it up. Already did that years ago for another project, and both my customer and I are still reaping the benefits
|
|
|
|
|
this madness looks like it could make you indispensable if you raise to the challenge!
|
|
|
|
|
No challenges here.
Another company owns the database, someone else sometimes works with it.
That someone else asked me if I could do him a favor and write that query.
Other than that the database is not used anymore and kept around for historical data.
I've got other (fun) challenges coming my way
|
|
|
|
|
Ha damn... You still sound like the man of the hour, nay, the man of the year!
|
|
|
|
|
I am!
I solve their problems, better, faster and cheaper than any other supplier they have!
|
|
|
|
|
The only difference between a mad man and a genius is that a genius knows that there is an int.MaxValue limit.
|
|
|
|
|
I once got to look into the table and variable name structure of BPCS. It, too, was a nightmare, and I can't believe it was a successful commercial venture. It might not have been as bad as the one you looked at. I don't know, because I cussed and closed it as soon as I could!
|
|
|
|
|
David O'Neil wrote: and I can't believe it was a successful commercial venture I always wonder about that too.
Not because the database is a mess, because users can't care less about that, but because if the database is a mess then it's likely that everything else is a mess too.
Maybe it's just this weird naming that's wrong with it, maybe the naming was generated by some tool, but the developers actually know what they're doing?
|
|
|
|
|
Sander Rossel wrote: OVER FORTY-ONE THOUSAND TABLES!
Wilco. Tango. Foxtrot. Echo.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
whenever i'm on a project and see a mismatch in the names in the database, the back-end and the front-end i immediately get the urge to kill everyone.
The part before the $ is actually a company name and it turned out this database has the same tables for 23(!) companies, and some other (un?)related tables, giving the database a staggering 41,000+ tables!
that's like creating 150+ tables a day for an entire year. part of those tables are created dynamically?
abandon project
|
|
|
|
|
Martin ISDN wrote: that's like creating 150+ tables a day for an entire year. part of those tables are created dynamically? I think it's the product of years of development and dynamic table creation, possibly created by a user directly from the product.
But I'm not sure.
Martin ISDN wrote: abandon project Because I don't like a database I have to access once?
Would be very bad for my finances
|
|
|
|
|
Be thankful... it could have been access...
or even better, excel tables
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: or even better, excel tables That's my next project
|
|
|
|
|
What can I say? I was young, and I needed the money...
Anything that is unrelated to elephants is irrelephant Anonymous
- The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944
- Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
|
|
|
|
|
The part before the $ is actually a company name and it turned out this database has the same tables for 23(!) companies, and some other (un?)related tables, giving the database a staggering 41,000+ tables!
Probably not intended, but this sounds like a great way to be GPDR compliant - each table can have different access controls so that someone who is allowed to view the data for $COMPANY_A will never be allowed to view the data for $COMPANY_B.
Unintended consequences, and all that...
|
|
|
|
|
Yeah, it's probably to keep one company out of the other's data, but giving them separate databases may have been a better option...
Also, I'm not sure if GDPR applies to businesses (it's all B2B)
|
|
|
|
|
Well, it seemed like a good idea at the time.
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
Because the unsupervised junior devs thought multi-tenant tables were too much work for the prototype, and when it needed to scale out management balked at paying for one database/customer or a major refactor of the tables to do multi-tenant the sane way so the juniors -still without any meaningful supervision - came up with a WTF pattern.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
Sander Rossel wrote: a staggering 41,000+ tables
Why go deep, when you can go wide? If each company has its own set of tables dedicated to it, think of how much faster queries are gonna run than if all the data for all companies was combined...
I'm sure that was the line of reasoning...
|
|
|
|