- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
It might be his frist divorce but sure not the last.
Admin
I half expected the logs to show all the information that had been deleted. Then all they had to do was using the logs as a basis for a script to reenter the information.
Admin
TRWTF is allowing data to be deleted through an interface which is accessible to non-administrative users. Why didn't Sergio just have a "deleted" flag?
Admin
TRWTF is of course the logs which detected Michelle's enemy action. The lawsuit is now on the other foot, to mix metaphors.
Admin
This thread is useless without pics!
Admin
Well, if you say so... [image]
Admin
+1 on the deleted flag but clearly Sergio was at the beginning of his career when he did that system. Regarding admin access: "You know, the brunette in the sales department with legs to die for and a smile that you couldn't resist.." Probably the sales dept. was tasked with maintaining the catalog..including deleting old products.
Admin
Second this. It seems odd to me that there wasn't a whole load of information/sales figures/MI/general auditing attached to each "product" that meant it couldn't be deleted (and should just be marked/flagged as 'discontinued' or such, maybe with a date)
But hey, none of our systems is "perfect", there's usually some kind of investment lacking.
Admin
Like I was in my 'log everything phase', though it would have been better if I wasn't still in the 'test environments are for wimps' phase.
Come to think of it, I restored someone elses data from the logs (my logs) too.
Admin
Sergio answers his phone at 2:15 in the morning, then calls the sales rep for the backup solution to wake him up too. Sergio doesn't even work for Peter anymore, yet he's still willing to interrupt the sleep of others to serve Peter. This Sergio guy is a real sociopath.
Admin
Admin
pah, deleting that actually deletes stuff ... why not just set a flag that product x is no longer valid -> easy to restore, all your references are dandy and disk space is not really an issue anyhow.
Admin
Admin
THIS is what should happen to clueless, cheapskate scumbag business owners.
Addendum (2013-10-03 08:18): THIS is what should happen to clueless, cheapskate scumbag business owners.
Seriously, far too often this kind of person thinks there's nothing wrong about cutting on anything to save a few bucks, and the "visionary" type is even worse because they constantly start new things to try and make it big while ignoring the one or two ideas that actually have merit.
This Peter character will get no sympathy from me, having worked for a similar "visionary" for 2 years and seeing this same kind of nonsense. Behavior like this should be punished swiftly and decisively to send a clear message that it is NOT OKAY to cut corners on essential business functions and software.
Admin
Sergio's mea culpa about it being early in his career aside, there are some essential lessons that every noob should learn at the beginning:
You touch it, you own it. It shouldn't be this way, but nobody seems to mind calling an old contractor from four years ago about their system. It happens, and often. Sergio even bought into it. Learn to capitalize on this and charge a (outrageous) consulting fee.
Learn how to properly model your schema. This means add a delete flag to merely inactivate a row
3, Audit trail. Add a complete audit trail to reproduce any database entry for each revision.
Oh, and a comprehensive HR policy that still protects the company from the actions of its CEO.
Addendum (2013-10-03 08:35): addenum to 1: Add to the restore/rebuilding operation every php/mysql/server software patch you can think of, including the proper configuration of the backup software. The shortsighted business owner will not think twice about approving every change. Put all of it into one quote.
Admin
You do realize that apart from Point 2, nothing is in the hands of the noob. And as an insider job, no amount of proper authorization scheme can protect you from it, if the brunette with legs to die for and a smile you couldn't resist is made the admin. More importantly, none of that works in small businesses, as the organisation size is small. The only place it can work is large organizations which tend to put gates to protect themselves from their employees and the most important skill that employees learn is how to protect your ass.
Admin
It appears the poor noob had some control over how some of the software got written, though the story doesn't really say. I would push for any of the above to be a non-negotiable part of the base system functionality.
Admin
Well, since the cat is out of the bag, there's nothing to stop the company from pressing charges against Michelle and suing her in civil court for damages. Of course, since Peter opened them up for possible labor violations by firing her, there will probably be some sort of settlement.
Admin
"available" != "free".....
Many years ago I supported a Medical Office System (which I wrote). There was one Doctor who was great in many respects, but would call (beeper in those days) for the slighted thing "which report has xxx field sorted?".
At first I simply provided answers. After some time we had a "heart to heart" (although he was an ENT), and established a "per call" charge [which was about 4 times my normal hourly rate - independent of how long the call was]
He continued to call, I continued to bill...He thought it was a good deal....I made a lot of money (although it can be difficult to give a good answer when it is 1AM and you have been in the Pub for a few hours...)
Admin
Before every n00b reading the comments goes ahead and alters all the tables they have at hand with a "deleted" column, I have to point out that for some data it might make sense, but not for ALL data. And even then, having a secondary table for deleted data makes more sense.
Admin
Yo dawg, I heard you like PICS, so I put PICS in your pic so you can pic while you PIC
Admin
I had a client enable a hidden debug log setting that dumped every INSERT statement to a log file, effectively duplicating their filesystem usage. Hard disk ran out of space and broke the database. After 6 hours and no results on recovering data we discovered the enormous log files, 10's of Gigabytes each. Flat text. On Windows.
Took a bit of finagling in Cygwin's Bash tools, but we extracted the INSERT queries from the log files, blew away the database, and re-ran the INSERT statements.
Huzzah.
Admin
Admin
Phoar! Just look at those legs on that PIC16F87A! Very shapely!
Admin
Real men stare at ARMs
Admin
Twist: CFO/wife did it, getting Michelle's password from the handy GUI, password123. Better check the VPN logs.
Admin
Except that if the CFO did it and the company goes down, she just lost the financial security provided by her husband's company...as a CFO, she's probably smart enough to realize she can be way beter off just by living on the alimony from the husband CEO...
CAPTCHA: persto, "When Michelle was fired, her account should have been disabled persto!"
Admin
The deleted flag is quicker to implements and easier to maintain. Using a deleted table permit faster table lookup, and as such is usually better when working with large amounts of entries, but it is pretty much negligible if we don't work with large entries.
As such, because it is quicker to implement, the deleted flag is usually prefered for small and medium-size projects.
Admin
The deleted flag can also lead to other bugs. (i.e. someone forgets to actually weed those rows out somewhere) but I agree, moving them to another table is overkill for smaller projects.
Either way, actually deleting things is something you only do when you're green enough to not realize that only like 50% of deletions, even by admins, are what they meant to do. (Even with a 22 step "are you really really sure?" process.)
Admin
I'm more of an ASIC man myself..
Admin
Admin
Real men focus on BUS Times and Memory [b]ass[\b]ets
Admin
Admin
Adding a "deleted" column to your database tables is a WTF and a sure-fire way of making the performance deteriorate steadily over time if the volume of data is significant (as all your queries must now do a full table scan for "AND deleted = 'N'")
Shift the data into archive tables if you really need to on Delete operations, where it will probably sit forever without ever being looked at.
Admin
Pretty sure you can just index the Deleted column to remove any table scan issues. Unless you are deleting and un-deleting items like crazy, won't really cost much of anything.
Admin
Accidentally showing deleted records versus accidentally deleting most records...hmmm...
Admin
And there endeth the lesson on free MySQL vs a REAL database ... transaction log rollback. Any 'client' front end is still going to perform SQL transactions behind the scenes. 40 hours of manual deleting just becomes a few thousand SQL inserts from a transaction log.
Admin
Per call only work when you can "terminate" the call. If they last "forever" (which some do), you can lose money.
This reminds me of a community that instituted "loudness" faults for concerts at their public venue. The charge was $$$/overage. The performers made sure that they were ALWAYS loud, and paid the single fee as an expense. The city revised the penalty schedule soon afterwards.
Life goes on.
Admin
Please post where you work so we can all be sure to never apply for a job there.
Admin
Nope, having an index on a boolean (deleted) and with a bad distribution on the value will probably still cause table scans.
Ben there, done that. Split table was better.
Admin
Admin
A full transaction log restore of 4 years time? That's not possible. You don't rollback a transaction log. You rollback a transaction. You replay a transaction log. As in you record every insert, update, and delete statement since the time of the last backup and replay them to a point in time when you restore the DB.
We run a 10 GB database in MS SQL. We backup the logs every 30 minutes, but once long ago we restored a backup to a different database for testing. That DB wasn't being backed up, but it was having the indexes rebuilt and reorgainized nightly and the web application could talk to it. In a month, the transaction log was about 25 GB in size. That's a moderately sized DB with zero users and a fair number of indices.
The live DB uses between 1 and 5 GB under normal operations every 30 minutes, meaning the transaction log is about 25 GB of transaction log data every day. For our year end procedures, though, it was enough to kick the log file to 17 GB.
4 years of that? That's over 35 TB of data. I don't even want to think about how long it would take an RDBMS to crunch through 35 TB of transaction logs, let alone if it even could.
Admin
We can't know what Michelle knew about the lack of backups. I'm pretty sure Michelle didn't even know what a backup is and she was sure that deleting the data will make it lost forever. Accidentally, she was right... Even if she knew what a backup is, she probably never thought about it, the anger clouded her mind. Just like the title says...
Captcha: illum. Let's illum Peter and explain him what a moron he is.
Admin
Most systems that have a soft delete also have a hard delete that the sysadmin can use to correct data that should not be in the database at all.
Additionally, systems that have a soft delete generally need to have a mechanism for purging or archiving data older than a certain point or you end up with a DB that never gets any smaller yet does not contain particularly current data, meaning your indexes had better include the entry date or your system will have to sort through half the disk for a basic query. Then you have to the whole issue of OLTP vs OLAP and performance considerations.
"Let's use soft delete" is all well and good, but it's not as simple as you're all suggesting.
Admin
Wouldn't it make more sense for any sort of e-commerce type of catalog to NOT actually delete data, you know for historical purposes?
Anyways as I said above, I've seen too many idiots like this guy cut corners everywhere because securing a server (or buying a decent one) is money they don't want to spend, or backups are too expensive, or because they don't want to pay for anti-virus because god forbid its $500 for their 5 salespeople. In most cases these people manage to stay successful for some God-forsaken reason despite doing everything WRONG and downright STUPID. I'm glad to see a story like this where the cheapskate asshole gets what is coming to him and learns the hard way that you skimp on everything, and when the shit hits the fan you're sunk. The only thing actually missing is the line that Peter went out of business and ended up bankrupt living on the street begging for money because that's the fate that these scumbags deserve.
Admin
This is not confined to "visionary" personalities, but is my only real gripe with all the fresh-out-of-college-and-off-the-last-flight-from-Bangalore contract programmers I've had to work with. The tech schools teach them about coding, but no mention of the concept of "maintenance".
The examples and exercises in the beginners' programming class I taught were designed to solve one simple problem, then refine or expand upon that same solution as each new language feature is introduced. My students quickly learn that it's not a good idea to throw away "yesterday's" handout.
Admin
Admin
Yep, once upon a time when I build my first database (which now some 8 years later is still running by the way.. shudder) I also made it use 'hard delete'. One day in the summer when the project administrator was on vacation one of the lower operators had to delete some faulty data and deleted 3 data groups instead of the intended three instances. Afterwards the person initially denied that he had deleted more than the agreed 3 instances until I could show the log showing that the administrator had deleted the groups (although he was on vacation, he had told the other person his password as only administrators could delete data!.., now there is a wtf!). Fortunately the deleted data was nonessential and could be done without, as it was first discovered some 3 weeks after so restoring from backups and adding correcting for data entered since would have been tedious...
I have since been more paranoid and only designed databases with 'soft delete' (in some cases by relocating to backup tables) so not to be in that situation again...
So long story short, we all have to learn initially, and I do believe that no-one no matter how good he/she is has never made a rookie mistake at some point in time.
Yours Yazeran
Plan: To go to Mars one day with a hammer.
Admin
No one seems to have brought up the fact that by calling this guy, the CEO learned who deleted the data. If he has a paper record of the date the employee was fired; and logs of the computer access the employee had used after being fired to bollix up the data, then
-- the employee committed a crime. Computer crime in this country could even be considered a federal offense, or perhaps even terrorism; the employee could be going away for a while.
-- the employee could be sued for damages. Materially harming the business could get a lot of $ for the owner.
This was certainly a worthwhile call for the CEO to make; and probably will be pretty lucrative for the consultant as well (how much would YOU charge for being a subject matter expert in a civil and/or criminal lawsuit?)
Admin
these data :)