Angry DBAs
-
By chance I landed on a very old thread on this forum and decided to rearchive this for your viewing pleasure and vocabulary:
[b]GGTIT[/b]
Short for God's Gift to IT. Describes a person involved with IT, which fails to realise their own shortcomings. Paired with authority, this results in the hall monitor effect. Often manifests in form of The Senior Systems Architect, The Senior Consultant or (most commonly) The Angry Senior Database Administrator. The latter are known for making the lives of in-house developers a real pain whenever they can.
[i]dev1: The DBA rejected our database layout. We're back to the drawing board.
dev2: What?! We spent three weeks designing that database! That douchebag really deserves some kind of GGTIT award.[/i]
[url=http://www.urbandictionary.com/define.php?term=GGTIT]source[/url][b]How to piss off the DBA[/b]
1. When working on a project that requires new tables and schemas wait until the day of release to production before bringing the DBA into the loop. When he scoffs at your table design tell the VP who wants the project done that the DBA is not being a "Team Player".
2. Load as much in line SQL as possilbe in your applications.
3. Create production processes that run on test. Then when they break or data is lost tell the CIO it's the DBAs fault.
4. Create a lot stored procedures that use processor intensive cursors.
5. Go up to your dba at 4:25 (he leaves at 4:30, you leave at 6) and ask him to push a change to production
6. When the DBA tells you that "this is a development issue.", respond emphatically, "NO - this is a database issue!"
7. Put all your business logic in your sproc
8. Tell the DBA, "But I need this change now - this is a production issue!"
9. Tell the DBA, "I need to make a new table."
[url=http://web.archive.org/web/20050204152539/angrydba.com/pissoffdba.asp]source[/url]
To everybody administrating and working with databases: We still love you. :)
-
@Shortjob said:
GGTIT
Short for God's Gift to IT. Describes a person involved with IT, which fails to realise their own shortcomings. Paired with authority, this results in the hall monitor effect. Often manifests in form of The Senior Systems Architect, The Senior Consultant or (most commonly) The Angry Senior Database Administrator. The latter are known for making the lives of in-house developers a real pain whenever they can.
dev1: The DBA rejected our database layout. We're back to the drawing board.
dev2: What?! We spent three weeks designing that database! That douchebag really deserves some kind of GGTIT award.
source
Reminds me of my last job's CTO. Didn't like FKs because they were "slow" and prevented him from adding rows to a table (because the master table didn't have the ID he was putting in). He also didn't like the idea of using ENUM('weekly','monthly','twice-monthly') for a column because it'd be "slow" and he "didn't know how ENUMs worked", so I suggested TINYINT as an alternative, he veto'd that and made it a VARCHAR(32) instead. He has no issue with tables that are all VARCHAR(255) columns, and in fact made multiple tables that are just a single BLOB storing encrypted CSV data (only two of the 19 columns in the CSV actually needed encryption) and so the report was an ugly monstrosity (full of subqueries, AES_DECRYPT, SUBSTR and CONCAT) despite our framework having a nice way to import CSV data into the DB with certain columns getting encrypted automatically.
-
@Lingerance said:
@Shortjob said:
GGTIT
Short for God's Gift to IT. Describes a person involved with IT, which fails to realise their own shortcomings. Paired with authority, this results in the hall monitor effect. Often manifests in form of The Senior Systems Architect, The Senior Consultant or (most commonly) The Angry Senior Database Administrator. The latter are known for making the lives of in-house developers a real pain whenever they can.
dev1: The DBA rejected our database layout. We're back to the drawing board.
dev2: What?! We spent three weeks designing that database! That douchebag really deserves some kind of GGTIT award.
source
Reminds me of my last job's CTO. Didn't like FKs because they were "slow" and prevented him from adding rows to a table (because the master table didn't have the ID he was putting in). He also didn't like the idea of using ENUM('weekly','monthly','twice-monthly') for a column because it'd be "slow" and he "didn't know how ENUMs worked", so I suggested TINYINT as an alternative, he veto'd that and made it a VARCHAR(32) instead. He has no issue with tables that are all VARCHAR(255) columns, and in fact made multiple tables that are just a single BLOB storing encrypted CSV data (only two of the 19 columns in the CSV actually needed encryption) and so the report was an ugly monstrosity (full of subqueries, AES_DECRYPT, SUBSTR and CONCAT) despite our framework having a nice way to import CSV data into the DB with certain columns getting encrypted automatically.That CTO of yours needs to discover XML, a technology which will allow him to continue working in the dark ages but with a veneer of respectability. Just shove your data into XML, store it in a large VARCHAR or TEXT column, and declare victory. Pepper your design documents with references to "The NoSQL Movement" and "Post-Relational Persistence Medium Design" and his victory will be complete.
-
@bridget99 said:
That CTO of yours needs to discover XML, a technology which will allow him to continue working in the dark ages but with a veneer of respectability. Just shove your data into XML, store it in a large VARCHAR or TEXT column, and declare victory. Pepper your design documents with references to "The NoSQL Movement" and "Post-Relational Persistence Medium Design" and his victory will be complete.
Nah, he hated XML. That didn't stop him from having a single column table where each row was a single line from a file, then he used a fuckload of SUBSTR and CONCAT in a subquery to get the actual columns (the file was fixed width).