1 / 23

Database refactoring

Database refactoring. For the beginning…. Avoid overspecialization. Barrier. Application developer. Database developer. Communication Cooperation Exchange of experience. Developer. Developer. Definition.

dooley
Download Presentation

Database refactoring

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Database refactoring

  2. For the beginning… • Avoid overspecialization Barrier Application developer Database developer CommunicationCooperationExchange of experience Developer Developer

  3. Definition • Refactoring of databases is the database schema change, improving its design, but not affecting its behavioral and information semantics. • It contains both structural and functional aspects

  4. What can we refactor in DB? DB keeps: • Data (are kept according to the scheme) • Stored code The stored code doesn’t differ from any other code (it should be tested) The scheme of data (tables, indexes, etc.) The availability of data complicates the refactoring of the scheme!

  5. Why should we refactor? • Correct the inherited database • Ensure the evolutionary development • Prevent the redundant design (over-design)

  6. Smells of bad code in database All the smells of codes can be applied to the stored code including: • Procedures-monsters • Spaghetti code • Code duplication • Oversaturation of the conditional operators • etc. Smells characteristic for DB: • Table/column of wide destination • Redundant data (repeated in several tables) • Table with a huge number of columns/rows • Smart columns (xml) • Lack of limitations (lack of validation) • Fear of changes in data scheme or procedure

  7. Fear of changes • The most «stinking»smell • Prevents the development • Reduces the effectiveness • Suggests an even bigger mess • Over time it becomes only worse

  8. How to proceed? • Create your sandbox of development • Transfer changes in the sandbox of integration • Introduce in production

  9. Sandboxes Frequent deployment Controlled deployment Highly controlled deployment

  10. The best case (the easiest)

  11. Worst case (the most complex)

  12. Trivial things • Is it possible to rename a column in the database without changing the hundreds of applications? • If we can not make such a triviality as we can do something really serious?

  13. Unit tests in the database • Is it too difficult? • Isn’t there a good testing tool (framework)?

  14. Running unit tests • Anonymous PL/SQL code • No need to change the database • Call raise_application_error a specific communication in case of an error • A rollback at the end of the test • Launch any SQL tools

  15. Example of a test

  16. Logs changes (changelog) • You must track changes • Writing delta-scripts (migration): • At the beginning of the transition period • At the end of the transition period • The same scripts for • Update sandboxes • Deployment on the production

  17. Simple script

  18. Versioning

  19. Teamwork • Developers • Close cooperation with DB administrators • Skills of operation with databases • Administrators of DB and designers of DB • Should be involved in developing the application • Skills of application development

  20. Testing tools • Delta-scripts • Dbdeploy, liquibase, deltasql • It's easy to write yourself • PL/SQL code, Oracle SQL Devepoler, Intellij IDEA

  21. Categories of database refactorings

  22. Categories of database refactorings

  23. Categories of database refactorings

More Related