Drive your dba crazy in 3 easy steps
•Download as KEY, PDF•
20 likes•15,829 views
The document describes 3 easy steps to drive your DBA crazy: 1. Start with a small project that grows increasingly complex without oversight, making someone responsible for the growing complexity. 2. Engage in confusing and nonsensical conversations about the project that frustrate the DBA's attempts to understand it. 3. Repeatedly violate the DBA's authority over and ownership of the database through dangerous or prohibited actions, disrespecting the DBA's expertise.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Drive your dba crazy in 3 easy steps
Similar to Drive your dba crazy in 3 easy steps (20)
More from Alberto Brandolini
More from Alberto Brandolini (20)
Recently uploaded
Recently uploaded (20)
Drive your dba crazy in 3 easy steps
- 1. Driving your DBA crazy in 3 easy steps a scary story by @ziobrando
- 3. @avanscoperta www.avanscoperta.it avanscoperta.wordpress.com alberto.brandolini@avanscoperta.it © Alberto Brandolini 2009
- 5. It grew
- 7. Somebody’s goBa be responsible for that
- 11. Useful
- 12. but sHll...
- 14. When it comes to run a query with 16 joins you’re the person to call...
- 15. When it comes to run a query with 16 joins you’re the person to call... You can say it loud, pal
- 17. I don’t know
- 18. I don’t
- 20. While Jack works
- 22. ...in bulk mode, of course
- 25. int Type = 1;
- 26. int Type = 1; st h is a td oe !!! W h ea n?? lin em
- 28. So you’d use a “readable data”, ... are you a communist or a lady?
- 29. Analyst Domain Expert Developer Developer Interviews Ubiquitous Language Whiteboard discussions Application Code Specs and Test Code documentation © Alberto Brandolini 2011
- 30. Analyst Domain Expert Developer Developer Interviews Ubiquitous Language Whiteboard discussions SQL Application Code Specs and Test Code documentation DBA © Alberto Brandolini 2011
- 31. So You want to speak the Ubiquitous Language, you scumbag? © Alberto Brandolini 2011
- 32. So You want to speak the Ubiquitous Language, you scumbag? The only ubiquitous Language is SQL! Every Database speaks it! © Alberto Brandolini 2011
- 33. What is a Type 1 you scumbag?! A Type 1 is a Type 1, sir! I can’t hear you!!
- 35. Accidental Domain Complexity Complexity Conventions Behaviour Primary Keys SemanHcs Joins Language Legacy encoding Conceptual integrity Replicas Context Boundary Stored procedures Domain Events Triggers
- 38. A new business requirement impacRng the applicaRon in 20 different points is an architecture problem
- 39. unsurprisingly, the more rules you have, the harder it is to evolve...
- 40. You can give your heart to DDD, but your ass belongs to the DB!
- 42. Your Toothbrush
- 43. Your Comics CollecHon Your Database
- 46. Your Database
- 47. THIS DATABASE IS MY DATABASE TRESPASSERS WILL BE SHOT SURVIVORS WILL BE SHOT AGAIN © Alberto Brandolini 2011
- 48. Bounded Context ‐ Context: a seSng where a word Shipping appears that determines its meaning ‐ A porRon of the system where the Ubiquitous language is consistent Payment © Alberto Brandolini ‐ 2010
- 49. He’s probably not going to like it © Alberto Brandolini 2011
- 51. add/remove Item Ready for Open finalize Closed select DeliveryAddress ShippingMode Selection select Shipping Mode Ready for Ready for Shipped ship pay Delivery Payment deliver Delivered return Returned © Alberto Brandolini 2011
- 55. Aggregate © Alberto Brandolini ‐ 2010
- 56. Aggregate A group of objects that naturally belong together Unit of consistency in the domain model updated in the same transacHon deleted together transferred together © Alberto Brandolini ‐ 2010
- 57. Aggregate <<Entity>> <<Value Object>> Order LineItem date goods A group of objects that customer amount quantity notes naturally belong together ... subtotal() update() ... close() Unit of consistency in the ship() ... domain model <<Value Object>> <<Value Object>> Money Customer currency updated in the same name amount surname address plus(Money other) transacHon minus(Money other) ... deleted together transferred together © Alberto Brandolini ‐ 2010
- 58. Customer add/remove Item Ready for addTocart Open finalize Closed select DeliveryAddress ShippingMode Selection select Shipping Mode Ready for Ready for Shipped ship pay Delivery Payment deliver Logistics Financial Dept Delivered return Returned Customer Care © Alberto Brandolini 2011
- 59. Different Domain Experts Different Goals Different Language Different Models Different Bounded Contexts Different Aggregates © Alberto Brandolini ‐ 2010
- 61. DuplicaHon
- 63. “Every piece of knowledge must have a single, unambiguous, authorita;ve representa;on within a system” Andy Hunt ‐ The Pragma;c Programmer
- 66. The cost of avoiding duplicaRon increases with scale
- 69. ... and by the way, we’re not violaHng the DRY anyway... :‐)
- 71. MulHple aggregates Money currency amount plus(Money other) minus(Money other) ... <<Entity>> <<Root>> <<Value Object>> <<Entity>> <<Root>> Order LineItem Customer date goods name customer quantity surname amount notes address ... subtotal() ... update() ... updateDiscount() close() ... ship() ... shipping address <<Value Object>> CustomerData billing address name surname <<Value Object>> Address <<Value Object>> street city country zipcode © Alberto Brandolini ‐ 2010
- 72. Th a g at’s g re M ga Y te? ...
- 73. Aggregate modeling Hp (from UDI Dahan): Group words according to the conversaRons you use them in, inclute aBributes, not only classes. Different Stakeholders/ Domain Experts will use different words to fulfill different goals
- 74. Events and aggregate coordinaHon ‐ OperaRons spanning mulRple aggregates shouldn’t be in the same Unit of Work ‐ CommunicaRon between aggregates <<Domain Event>> is inherently asynchronous OrderPurchased ‐ Domain Events as a communicaRon order where mechanism when amount ‐ from the outside payment method ‐ among aggregates ... ... © Alberto Brandolini ‐ 2010
- 75. Asynchronously responding to events <<Domain Event>> OrderPurchased order where when amount <<Entity>> <<Root>> payment method s u bs <<Entity>> <<Root>> s to ... cri b Order su b s c ri be e s to Customer date ... name customer surname amount address ... ... onPurchaseEvent(...) onPurchaseEvent(...) update() updateDiscount() close() ... ship() ... ‐ Don’t forget: Business rules everything!!! © Alberto Brandolini ‐ 2010
- 77. ! Single source of truth? © Alberto Brandolini ‐ 2010
- 78. ! Single source of truth? ‐ Once it used be paper... © Alberto Brandolini ‐ 2010
- 79. ! Single source of truth? ‐Once it used be paper... ‐ now the best candidate is Events © Alberto Brandolini ‐ 2010
- 80. That’s gonna make him REALLY angry © Alberto Brandolini 2011
- 83. Does it really have to end like that?
- 84. E’ necessario un processo di sviluppo agile, che permeBa di raccogliere il feedback di utenH e Our goal is to establish a creaHve domain experts, in iterazioni brevi. collaboraHon © Alberto Brandolini 2009
- 85. We did it with the worst Domain Experts... can’t we do it with the DBA? © Alberto Brandolini 2009
- 86. We did it with the worst Domain Experts... can’t we do it with the DBA? © Alberto Brandolini 2009
- 87. Humble Tips:
- 89. Start small
- 90. Work Safely
- 91. Share the fun
- 92. Behave
- 94. Thank you alberto.brandolini@avanscoperta.it hBp://ziobrando.blogspot.com twiBer: ziobrando
Editor's Notes
- \n
- \n
- And that&#x2019;s the company I started one year ago.\n
- Think of &#x201C;So spoke zarathustra&#x201D; as a soundtrack here :-)\n
- \n
- It&#x2019;s at the center of every operation. Is the cornerstone of every IT service. One cannot even dream of an IT service without it.\n
- \n
- Enter Jack, our DBA or &#x201C;Data Oriented Person&#x201D;. He&#x2019;s the person you&#x2019;ll have to argue with at a given moment, when you try to build something different from the same old stuff.\n
- And that&#x2019;s the realm of Jack. The E-R Diagram, where complexity means power. \n
- Is this diagram really useful? Yes. Perfect for covering the table. Developing software is another thing.\n
- \n
- Jack is the person to call to solve complex and intricated problems. The fact that maybe he&#x2019;s also the origin of complex and intricated problems is often obscure to the business side of the company.\n
- Jack is the person to call to solve complex and intricated problems. The fact that maybe he&#x2019;s also the origin of complex and intricated problems is often obscure to the business side of the company.\n
- This used to be a question that struck me after giving a talk about CQRS and DDD. A guy in the audience asked me how did I face this problem.\n
- And honestly I didn&#x2019;t know.\n
- But even more honestly, I&#x2019;ve never had the chance to face a query with 16 joins. Not in the applications I&#x2019;ve designed. I suspect this has something to do with my design style.\n
- Because instead of starting the application from a data model, I normally start designing it around a domain model tailored for specific use cases.\n
- \n
- Many times, the work of the Data-Oriented Person is obscure to me. Sometimes I get presented with a Data Model even if I&#x2019;ve never asked for one. Sometimes I get forced to use one. More often than not the DBA needs to know what our team is doing while we cannot know what the DBA is doing.\nSometimes it&#x2019;s definitely worth a look.\n
- Ans sometimes he&#x2019;s just trying to solve the wrong problem.\n
- That&#x2019;s one nasty thing we might encounter while dealing with legacy data model.\nIt takes half a movie to realize that redrum is really murder. But DBA love encodings and the like.\n
- That&#x2019;s one thing Data Oriented People love. Giving conventional names to things.\nPicking the names from the domain is not an option.\n
- But for Domain Driven Design practitioners, this line of code SCREAMS!\nWhat does this code mean?\n
- And of course this means something for the creator, but for us, poor explorers of legacy mess the mening is obscure.\n
- Asking for a different coding convention, might result somewhat unpolite, sometimes. Remember, conventions are always clear for the creator. And the creator ha probably been promoted...\n
- Yes, that&#x2019;s what we want to do in DDD. We want/need to speak same the Ubiquitous Language in every aspect of software development, with every role involved. It works. It&#x2019;s cool. It&#x2019;s fun.\n
- But for some reason, DBAs are untouched by this approach. And they don&#x2019;t care.\n
- Apparently they have good reasons for not changing theis approach.\n
- And to be effective in such a workplace, one needs to learn all the different tips and tricks of the legacy system. Becoming part of the legacy.\n
- Is this the right complexity to learn?\n
- I bet not. We are wasting our time on accidental complexity. One that&#x2019;s not part of the domain, but part of the (wrong) solution somebody designed before us.\n
- But this complexity has costs. Few measure that, but have a look to how much time is necessary for a newcomer to be productive in such a scenario. You&#x2019;ll have interesting results. Disappointing, I suspect.\n
- The lesser, the better. But what about your workplace?\n
- And ...let&#x2019;s sat that. Business people are not sadistic monsters. They are simple minds after all. They probably can&#x2019;t imagine an incredibly complex requirement. It&#x2019;s our solution that&#x2019;s messy.\n
- It&#x2019;s a software architecture problem and it&#x2019;s an organization problem. Hope nobody gets offended here, but this is an organization which is 2000 years old. Plenty of rules and dogmas, make it roughly impossibile to change without getting into contraddiction. To avoid contraddictions ...the organizations stand still.\n
- Some things are definitely harder to change.\n
- Let&#x2019;s talk about something different. About sharing the things you care about.\n
- This is one little cheap thing you don&#x2019;t share. I wonder why?\n
- That&#x2019;s another thing you don&#x2019;t share. You can show it to your friends but they&#x2019;re not allowed to touch it.\n
- That&#x2019;s not different for your Harley Davidson. Friends can have a look. Good friends can even touch it. But nobody can ride it except you.\n
- That&#x2019;s the same with the operating room. Surgeons do not share it. Nor do they share their tools. They need a sterile environment. You don&#x2019;t turn a little hospital into a bigger one by putting the operating room in a large shared open space. And what used to work in a little hospital is not necessarily good for a bigger one.\n
- And that&#x2019;s the one. You don&#x2019;t share your database. Yes, you got it: you don&#x2019;t share your database.\n
- I mean it. No one reads from my database. I will change table names and schema. Without dropping you a note. I don&#x2019;t care if this is causing a bug in your system. Your fault. This is MY database and I am the only one allowed to read and write. Tomorrow it will be different, and next week it might be a NoSQL. But will still be MINE.\n
- Enter the DDD concept of Bounded Context, that&#x2019;s where our database lives. We need to be coherent and consistent with the language and this is a viable strategy only if we don&#x2019;t share our database.\n\nOf course, there might be data sharing. But in a format that&#x2019;s designed for data sharing. With different evolution needs.\n
- What does it mean ...YOUR database? Every database is mine. Following my conventions.\n
- Let&#x2019;s see it from another perspective\n
- This looks like a state diagram, something our analyst might have sketched to illustrate a business process. So looks like an Order is passing through many different phases.\n
- But that&#x2019;s not an Order even if it might refer to the same concrete entity, not all the workflow needs to map to the same class.\n
- If we do that ...that&#x2019;s the mess we&#x2019;ll generate!\n
- And we&#x2019;re not even in the same aggregate. But to be clear about this we need to clarify a little more about what a aggregate is in DDD\n
- The next key DDD building block is Aggregates. The Domain Model isn&#x2019;t flat. Some links are stronger than others (and UML doesn&#x2019;t really help much in rendering it).\n\nIf we start considering consistency and behaviour as the primary drivers for modeling our domain we&#x2019;ll end up with something quite different from a 1-1 projection of the data model.\n
- The next key DDD building block is Aggregates. The Domain Model isn&#x2019;t flat. Some links are stronger than others (and UML doesn&#x2019;t really help much in rendering it).\n\nIf we start considering consistency and behaviour as the primary drivers for modeling our domain we&#x2019;ll end up with something quite different from a 1-1 projection of the data model.\n
- A model is a tool to solve a problem. We have different stakeholders/roles here each one with a different problem. Are we really thinking that a single model will solve them all?\n
- In fact different goals will be the territory of different domain experts speaking their language. Which is tailored around their purpose. To solve different problems we&#x2019;ll have multiple models.\n
- Are you prepared for that?\n
- Yeah, duplication. The root of all evil. Are you ready for that?\n
- You obviously don&#x2019;t like duplication. Because you&#x2019;re adhering to DRY.\n
- Everybody apparently is following DRY. So I took a look to the original statement. Which is a little more sophisticated than duplication is evil.\n
- Read again Any Hunt&#x2019;s definition, and read also the interview at http://www.artima.com/intv/dry.html\n
- \n
- If it&#x2019;s just me... I don&#x2019;t repeat myself. If it&#x2019;s just my team, then we communicate and we share a vision about our system. But if it&#x2019;s two or more different teams then the cost of communication is significant, and sharing might not be the most efficient way to deal with this specific issue.\n
- How big is the system we&#x2019;re talking about? Can&#x2019;t it be our bounded context?\n
- Sharing a piece of code means coupling. If you reuse my piece of code then coupling is introduced in the system. When I refactor I&#x2019;ll need to double check against external test suites also. Flexibility has a higher price, and sometimes I am not willing to pay for it.\n
- Yes, we don&#x2019;t need many justifications...\n
- Because data and behaviour are different. And data can be the same, but with different roles within the system.\n
- For example, in this case we&#x2019;ll notice some duplication, related to customer. But lifecycles of the customer and of the order are different. If a customer moves, we don&#x2019;t want to have all of our past orders changed, at the same time if an order needs to be canceled, we don&#x2019;t want the user to get down the sink as well. \nA little duplication is what allows aggregate lifecycles to be independent.\n
- If we don&#x2019;t want to have any duplication at the data layer... that&#x2019;s the mess we&#x2019;ll end up living in.\nIt&#x2019;s called Hell.\n
- Focusing on the language can be a good technique. And rarely aggregates come from our legacy data model. You&#x2019;d better forget about it. And start thinking from scratch.\n
- How to coordinate communications between aggregates? Well ...DDD now is focusing on Domain Events.\n\n
- Domain Events as a communication means between aggregates really simplify things a lot, even at the conceptual level.\n- Do they really belong to the same transaction?\n- Would you want the order to roll-back if you are unable to process the discount for the next order by the same customer?\n\n... but really, how the two things should be related, ...is a business choice! We just have more and more possibilites in our arsenal.\n
- Surprisingly, but Udi Dahan and Greg Young in their speeches at last DDDx put the paper-based system at the center of their vision. If a complex system could work without computers ...there must be a reason for that. Sometimes computers just overloaded the systems with more unnecessary complexity.\n
- There might be inconsistencies in the data or between the data and the paper. In many system (especially those data-entry based) the paper used to be the Single Source of Truth, but larger integrated systems Events are probably a better candidate.\n
- There might be inconsistencies in the data or between the data and the paper. In many system (especially those data-entry based) the paper used to be the Single Source of Truth, but larger integrated systems Events are probably a better candidate.\n
- You mean the Database is not the center of things anymore? Not here!\n
- So Jack is going to be Angry and trying to rise some consistency or security issue.\n
- But since we did our job well, he&#x2019;ll be thwarted by our system performances, and the old architecture will look like an ancient nightmare....\n
- \n
- That&#x2019;s not the way we&#x2019;re supposed to work.\n
- We strived to establishe a good collaboration with the domain expert...\n
- \n
- There&#x2019;s not a rule. Talk with the people. Some of them are nice. Understand their needs.\n
- Do not start from huge refactorings, unless the problem is really small (only ...the legacy solution is large)\n
- Do not take any unnecessary risk. Keep backups, and ensure security policies are respected.\n
- You&#x2019;re having fun, and they&#x2019;re not. Nobody likes to be treated like the old boring guy. You&#x2019;re doing something new, involve them.\n
- Be a fair person. Even if you don&#x2019;t like their approach do not surprise them with nasty moves.\n
- So that also Jack might find a happy place in the picture.\n
- \n