I read a story about a guy from Greece who wants to delete his gender from his id and my first thought was how many 20 year-old government database schemas that is going to mess up.

I really need to let this out somewhere...

Why the f...? Srsly.. Why would anyone do that? I'm joining another project. Apparently lead dev has adopted a coding style, where:

1. Every dev writes code however he likes, i.e. no clean-code requirement at all.
2. All services are crud-only. I mean all service classes. All must have those 4 methods; no more, no less.
3. Half of the business logic is inside controllers.
4. Not a single comment... Interfaces, models, etc. -- not a single one.
5. Xmls -- tabs, classes - spaces.
6. Xml schemas are downloaded with each build rather than stored downloaded once and stored locally.
7. I can keep going on and on.

Is it just me or are these some really weird decisions?

Five years learning how to build normalized information schemas to end up designing denormalized DBs.

We just got into a malicious bots database with root access.

So guard duty gave us some warnings for our tableau server, after investigating we found an ip that was spamming us trying all sorts. After trying some stuff we managed to access their MySQL database, root root logged us in. Anyway the database we just broke into seems to have schemas for not only the bot but also a few Chinese gambling websites. There are lots of payment details on here.

Big question, who do we report this to, and what's the best way to do so anonymously? I'm assuming the malicious bot has just hyjacked the server for these gambling sites so we won't touch those but dropping the schema the bot is using is also viable. However it has a list of other ips, trying those we found more compromised servers which we could also log in to with root root.

This is kinda ongoing, writing this as my coworker is digging through this more.

Hired a new BI developer. She tested reasonably ok in SQL, and certainly showed good strengths in visualising data, plus had a good attitude in the interview. We hired her. She broke her laptop the first day. We got her another then she complained the camera didn't work but didn't realise the lever in front of the camera was to move the privacy shutter off and on.

Assigned her some work of taking queries that are used in a BI tool that targets the transactional database directly, and re-jigging them for Snowflake which we're using as a data warehouse now, aggregating all our data into one place. Yet, she's struggling to understand why the SQL query she's pasted in doesn't work as-is.

I go over it again; the source schemas and tables are this, but in Snowflake we've named them this. She then bemoans how much work that is to change them all - I say use find and replace. She then struggles with Snowflake syntax errors and asks for a guide on T-SQL to Snowflake. I show her Google and say "this is what I did when I hit these problems - search for 'Snowflake equivalent to T-SQL getdate()' or 'how to get current date in Snowflake' but she still doesn't understand. I ask if she's every had to work between T-SQL and MySQL or MySQL and PostgreSQL or Oracle and so on and she says yes. I say the syntax isn't the same, is it? And she goes oh, now I understand.

She scored reasonably in her SQL test but I'm now concerned there's something fundamental missing in her grasp of SQL. I gave her a detailed demo of the tools, I explained in the interview and on her start about our move to a data warehouse for all our apps, and put her through some training plus gave her time to work through our Confluence pages - not expecting she'll remember everything, but more to ensure she recalls they exist and what the general contents are.

Anyhow, that's my rant.

SQL Rule 1. Always assume there are external processes that might affect your data. (for instance, triggers).
SQL Rule 2. In Denormalised data, never execute logic on dependant table values, always copy from the parent.
SQL Rule 3. When Denormalised data schemas are created the DBA knows what they are doing.
SQL Rule 3.1. If DBA knows what they is doing then according to Rule 1 there is no problem with adding in some triggers to maintain data clones as they are created.
SQL Rule 4. If you don't like or agree with triggers, deal with it. They are a first class tool in a first class RDBMS. In a multi-app or service environment there may be many other external processes massaging your data
SQL Rule 5. If all previous rules are not broken and the system has been running efficiently for many years DO NOT complain that there are triggers in the database that are doing and have been doing the same process that you just butchered (by violating Rule 1 and 2) in your makeshift "hello world, look what I can do from my phone" angular BS when the rest of the users are still relying on the existing runtime app.
SQL Rule 6. If you turn my triggers off, you sure as hell better turn them back on!

Today was a manic-depressive kind of day. Spent the morning helping some developers with getting their code to run a stored procedure to drop old partitions, but it wasn't working on their end. It was a fairly simple proc. But working with partitions is a little like working with an array. I figured out that they were passing the wrong timestamp, and needed to add +1 to delete the right partition. Got that sorted out, and things were good. Lunch time.

After lunch I did some busy work, and then the PO comes up at about 2PM and says he's assigned some requests to me. The first was just attaching some scripts. Easy. The second, the user wants a couple of schemas exported ... at 6PM. I've been in the office since 6:45AM.

While I'm setting up some commands to run for the data export, a BA walks up and asks if I'm filling in for another DBA who is out for a few weeks. Yep. There's a change request that hasn't been assigned, and he normally does the work. I ask when it's due. Well, the pre-implementation was supposed to be done in the morning, but it wasn't, and we're in the implementation window ... half way through. I bring up the change task, and look at. Create new schema and users. That's all it says. The BA laughs. I tell I need more to go on. 10 minutes later he sends an email with the information. There's only two hours left in the window, and I can only use half of it, because the production guys have to their stuff, and we're in their window. Now I'm irritated, because I'm new to Oracle, and it's an unforgiving mistress. Fortunately, another DBA says he'll do it, so that we can get it done in time. But can't work it either, because Dev DBAs don't have access to QA, and the process required access for this task. Gets shelved until the access issue is resolved. It's now after 4:15PM. I'm going to in traffic with that 6PM deadline.

I manage to get home and to the computer by 5:45PM. Log in. Start VPN. Box pops on screen. Java needs to update. I chose skip update. Box pops up again. It won't let me log in until Java is current. Passed.

I finally get logged in, and it's 6:10PM. I'm late getting the job started. I pull up Putty and log into the first box, and paste my pre-prepared command in the command line and hit error. Command not found. I'm tired, so it's a moment to sink in. I don't have time for this.

I log into DBArtisan and pull up the first data base, use the wizard to set the job, and off it goes. Yay. Bring up the second database, and have enter the connect info. Host not found. Wut? Examine host name. Yep, it's correct. Try a different method. Host not found. Go back to Putty. Log in. Past string. Launch. Command not found. Now my brain is quitting on me. Why now? It's after 6:30PM. Fiddle with some settings, reset $Oracle home. Try again. Yay. It works. I'm done. It's after 7PM.

There is nothing like technology to snatch the euphoria of a success away from you. It's a love-hate thing, but I wouldn't trade it for anything else. I'm done. Good night.

So, part of my job is working with SQL. Not my favorite technology to work with. But the tables have mostly non-descript fields, multiple schemas in the same table, and encoded relationships spanning multiple tables. Yes, the database from hell! On top of that, there is very little documentation on this mess. -- And my boss wants me to write queries against a combination of these tables to make sure the program is working. RIGHT...

I JUST HAD ONE OF THOSE DAYS THAT MAKES ONE WANT TO BANG TWO BRICKS ON HEAD SND END THE PAIN THE STORY STARTS YESTETDAY WITH ISSUES AFTER A MIGRSTION AND THEY ASK ME TO HELP TROUBLESHOOT EVEN THOUGH I'M A DEV DBA AND THE ISSUE IS IN QA/SAT AND I HELP ANYWAY AND THEY CAN'T FIND A VIEW AND SO I LOOK EVERYWHERE AND CAN'T DOING IT EITHER AND IT DIDN'T EXIST IN PROD OR DEV SO I TELL THEM IT'S NOT THERE, AND THEY ARE LIKE, CAN YOU RETRIEVE IT FOR US AND I'M LIKE FROM WHERE? I DON'T KEEP VIEWS IN MY BUTT AND YOU GUYS ARE SMOKING CRACK AND THE GIVE ME THEIR QUERY WHICH CONTAIN THE VIEE ANYWAY AND THEY SAY CAN YOU RUN IT AND IT RUNS AND WORKS AND THEY CAN'T MAKE IT WORK AND IT WORKS BECAUSE IT DOESN'T CALL THE VIEW THEY HAVE ME SO NO PROBLEM THERE SO I FINALLY ASK THEM ARE YOU POINTING TO THE CORRECT DATABASE AND THEY'RE LIKE OH MAN WE TOLD YOU THE WRONG DATABASE AND SO I LOOK AT THE RIGHT DATABASE AND FIND THAT THE GRANTS ARE MISSING AND YEAH THANK YOU FOR TAKING EIGHT HOURS OF MY LIFE BECAUSE WE WERE IN THE WRONG DB YOU GAVE ME AND I HOPE THE FLAG OF A THOUSAND CAMELS INVEST YOUR ARMPITS AND THE CHIGGERS OF A THOUSAND SOUTHERN LAWNS INGEST YOUR SOCKS AND UNDERWEAR. YAAAAAA!!!!

Creates PHP scripts for development SQL server, pushes to production to find out the schemas are different. *face palm*

Come on guys, use those JSON schemas properly. The number of times I see people going "err, few strings here, any other properties ok, no properties required, job done." Dahhh, that's pointless. Lock that bloody thing down as much as you possibly can.

I mean, the damn things can be used to fail fast whenever you misspell properties, miss required properties, format dates wrong - heck, even when you want to validate the set format of an array - and then libraries will throw back an error to your client (or logs if you're just on backend) and tell you *exactly what's wrong.* It's immensely powerful, and all you have to do is craft a decent schema to get it for free.

If I see one more person trying to validate their JSON manually in 500 lines of buggy code and throwing ambiguous error messages when it could have been trivially handled by a schema, I'm going to scream.

I received a few XSD schemas from service provider, this have literally: Table1, Table2, etc... Table21. and without any documentation.

Should I insult provider devs on email?

So, today is the final day of my internship, and I was almost done, until my fucking assface of a client calls me, and suddenly want 10000000 fucking things changed in a database, and I'm not just talking "Could you add this field?" Or make this default to that, no I'm talking change of relationships, schemas and the whole shebang, oh and suddenly the product also needs localization for 3 fucking languages, but it hasn't been built for this shit. Thank God my assessment was yesterday, I just noped right out of here.

People, don't be dicks, think what you want your product to be before starting the development

When do you know something is being overdesigned or overengineered?

The applications that the other programmer started building are killing me. He's using Clean Architecture and it has like a million different classes and shit. It's not messy or anything, but fuck it's overwhelming.

Just to figure out wtf was happening when getting the currently signed in user's email, I had to go through like 30 folder and files. Maybe more. All files were fairly simple on their own, but the entire flow was mindfucking me. Use cases, schemas, gateways, repositories, entities, models, etc etc

And that's the client facing application, I haven't checked the API yet, though it seems like that one is simpler.

The worrying aspect here is, any time anyone else has to mess with this, they'll also have to deal with this shit. This needs some really good documentation.

There's very little good use cases for mongo, change my mind.

Prototyping maybe? Rails can prototype, create/update/destroy db schemas really quickly anyways.

If you're doing a web app, there's tons of libs that let you have a store in your app, even a fake mongo on the browser.

Are the reads fast? When I need that, use with redis.

Can it be an actual replacement for an app's db? No. Safety mechanisms that relational dbs have are pretty much must haves for a production level app.
Data type checks, null checks, foreign key checks, query checks.
All this robustness, this safety is something critical to maintain the data of an app sane.

Screw ups in the app layer affecting the data are a lot less visible and don't get noticed immediately (things like this can happen with relational dbs but are a lot less likely)

Let's not even get into mutating structures. Once you pick a structure with mongo, you're pretty much set.
Redoing a structure is manual, and you better have checks afterwards.

But at the same time, this is kind of a pro for mongo, since if there's variable data, as in some fields that are not always present, you don't need to create column for them, they just go into the data.

But you can have json columns in postgres too!

Is it easier to migrate than relational dbs? yes, but docker makes everything easy also.

What is the purpose of using MongoDB and then adding mongoose?
If you want schemas, relations and all the jazz mongoose offers, have you considered using a RDBMS instead of a datapile system? Most (probably all) SQL databases support schemas, relations and all the jazz you seem to need.

So, ask yourself: Do you really need the functionality of a NoSQL database or do you just want it because it's shiny and new and "everybody uses it (tm)"?

I think karma is doing me a favor today 😍

So I started to work fir my current company early January 2017, on a project I'm still currently working on (well, now discussions are made around the next sprint, so I'm working on something else but you get the spirit)

We had the most PAIN-IN-THE-ASS-ish client I ever met. Dude gives schemas of what a page should look like (no real visual model but well things were pretty clear so there weren't big problems around).

The client was the kind of dude that could send these models, let us work on them then opening a fuck-ton of tickets, ranting about how the elements' display isn't good. Then we have to make remember him that he gave us nothing else, and he agreed on the functional specifications. And this for two WHOLE fucking years

Today, the project director came by our office and casually sat down next to me to tell me that the dude have been fired by his company for being a huge douchebag, blocking communication between us and simply being useless.

The sun is shining again 😍😍

5am now and trying to do a production deployment. It just failed because boss loves making un-approved changes to prod that change entire database schemas. Argh!!

Web service consumer: hey I need you to add new methods to this service

WSC: hey I need you to change the functionality

WSC: hey here are four new lists of fields to return from your service.

WSC: hey what are you doing the schemas are completely different now!! This has caused a lot of work for us

God, these people...

Little backstory. I'm making an training application and we have a MySQL database set up where some elements of the training are configured. This is so learning experts can easily change some aspects of the training without programmer's help.

Meanwhile, I'm also in the middle of a server migration, because our current server is running a lot of deprecated software and is in dire need of replacement.
This is going pretty slowly, though, because of other, high-priority, work that keeps being shoved my way.

Now, someone accidentally deletes a bunch of data from one of the schemas. No big deal in my book, the training is still in development and we have nightly backups of the database.
So I shoot a support ticket to the hosting provider and ask them to restore a specific schema, telling them to restore the image to some other machine and dump the tables in an MySQL file so I can restore it that way.
I also told them to get the backup of the OLD server, not the NEW one we're still migrating to.

About an hour later, I get a message that they dumped the schema's files in a Temp folder on the D drive. So I RDP to the server to check and... The files aren't there. Just before writing a response asking where the file is, I remembered the server I was migrating to and checked that server, and there were the files.

I had already migrated part of our databases and was testing compatibility before I moved to something else.
The hosting provider just dumped the files of the wrong server, despite me telling them exactly which server to use.

This is not the first time this hosting provider has let me down...
I'm really considering jumping to another if they keep doing this...

Yesterday, one of the consumers of my web service complained that I had made a lot of work for him by changing the schemas for said service.

Today, I was about 20 minutes from hitting ‘commit’ and mailing him the final details for the service & declaring it done.

He comes by to ask me to put a feature back in that I took out earlier at his request. I commented it out last week and just this morning finally deleted the comments in preparation for submitting the final build

An open source alternative to GraphQL with more features and less schemas.

Question about PR best practices.

I work for an analytics company and often have to implement new ETL steps. The data transformations in these steps can be complex and the major changes are usually 500+ lines up to around 2000 (the last one had 765 lines just for schemas).

What's the best way to split up the changes into multiple PRs, bearing in mind that it isnt guaranteed that a file won't change as the change is built up?

I dont get it. Please give me one good reason to use mongoose with a mongoDB.
Once upon a time it might have made sense to use a schema for the db. Today the native driver supports schemas and can check them on inserting. Nevermind one should validate the data before its hitting the db. I listened to an 1hr podcast last week where one of the maintainers tried to give reasons why its might be a good idea to use mogoose, and he failed miserably.
It introduces dependencies that are useless, it doesnt really abstract anything useful from the native driver, its TS support is shit and I dont like the API.
Every time I see someone use it he either fails or doesnt explain at all why to use it. Its so redundant it makes me angry. We have enough abstraction already. We really dont need more code that doesnt provide value. Please just use mongo the way the people of mongoDB intended it to be used.

I can't stand when people spend a single day familiarizing themselves with a new technology or concept and then come to the conclusion that's it doesn't work and really the old way is great. Not saying all new things are better. In fact, I'm probably more in favor of tried and true methods than shiny new methods. But one day? Really? That's all it took? In this particular case it's code-first DB development. Again, I'm not a fan myself really. But I have a co-worker who said creating tables and and schemas is much harder using code-first instead of DB first. I mean... Neither are hard. I personally think it's easier for basic things like tables and schemas but either way it's not hard. Now SQL triggers and index's all that fun stuff? Yeah code first is probably more complicated (I'm clearly not a database expert or anything). But a day? Really? You know enough to force a design paradigm on the whole company now? Wtf.

- Dictate the user experience of the product
- Get it built automatically by IDE - backend, frontend, whatever, everything.
- Customizability options - make changes to UI, backend structures, database schemas and models

- all of this by just talking in normal human language.

Okay soo I’m not a database guy.. I’m an embedded engineer but I’m helping one of my interns make a hardware tracking database... so we are tracking assembled products (dev samples).. but also tracking the pcbs within the product.. depending on the product it might have more than one pcb or contain other components to track.

The question is how would I set up the relationship in the tables, so depending on the say “type id” of the product it would link to a table full of feilds specfic to that “type”.. say the product is of type phone and has a pcb of this and a camera of that.. blah blah blah.... but say another product is of type “washing machine”.. which has no screen, it has a different pcb, but also has other things..

There would be a type table .. washing machine, phone, tv, camera, pcb, ecu.. etc.. but those type would need their own tables...

I guess the question is how to relate a field to different tables depending on the value of the field... is this portion all done thru query results and logic rather than pure data base schemas?

What would be the question in terms of database lingo to google search the answer lol

I am freaking out as se hace lo ir schemas and in all of them table structure is different... Doesnt people know about tools like Liquibase ?...