Comment by aleda145
5 days ago
I totally agree on investing in a sane data model upfront. So many production systems have schemas that only made sense to the engineer that created them. I would be delighted if I can read a schema and understand what a column means without having to dig through a bunch of migration PRs.
I recently encountered `is_as BOOL` in an important table. After way too much invested time we found out it meant "is active service". </DDL rant>
I integrate with many ERPs and this is the bane of my existence.
One of the worst has field names like `ft_0001...N` and table names like `UNCC_00001...N`, all in `text` fields (even numbers!), zero FK, almost no indexes and what are views?
The other has this funny field that is a blob that need decoding using a specific FreePascal version. The field? Where is the price of the product.
Other has, in the same column, mix of how handling "," or "." for numbers and I need to check the digital places to deduce which.
FUN.
P.D: I normalize all this Erps into my own schema and has get praise for things like, my product table is called products.
I may have worked with that one. Did it have a parallel schema that mapped tables and fields with legible/customisable names, so every SQL call had to join the mapping tables to hit the required table and fetch the fields you were after?
Wrote a Windows .Net program once upon a time to convert the data from other financial CRM systems into the system I worked on. Built a data mapping tool as no customer we onboarded placed "custom" data in the same tables or fields even when using the same financial system.
I actually miss doing that kind of work, my brain seems to be wired to find it fun. Writing SQL is one thing I don't delegate to an AI or even an ORM like Doctrine.
Who knows. I interface with a mirror of this non-sense copied into another db, and then it transfer to it to the original thing.
Why I not allowed to do things directly? For the same reasons the tables are like that
I think the best db schema I had the displeasure of working with was one where it was a requirement that every table and column name NOT have vowels, except for the few that could, and "the few that could" were governed entirely by a spreadsheet owned by the DB admin.
And so you got tables like LANDMRK and columns like RCR_RCRDR.
Oh my. What could possibly be the justification for this?
I work with an Oracle database like this. In the old days, there was a 30 character limit on column names, so you end up with conventions like no vowels. The limit no longer exists today, but the DBA continues to enforce the limit on new columns.
I never got an answer when I asked. This same government agency also got extremely mad when our dev manager upgraded the ASP.NET version for one project because it had some really useful features we were developing with. They deleted his permissions to deploy to production from there until the end of time, requiring us to email someone each time we wanted to update the application. It was great.
Postgres has COMMENT ON to help with this but descriptive names are helpful.
> I recently encountered `is_as BOOL` in an important table.
Sounds like a table designed by Forrest Gump.