|
|
|
Database Development. Our Process.
We recognize that every client's database needs are different, so we necessarily have flexibility in our process for designing and tuning our clients' databases.
In almost every case, however, we produce entity-relationship (E-R) diagrams in order to have a visual representation of the database. This is helpful for both new and existing databases, because it gives us a map of an arrangement that's otherwise hard to visualize. If the client has an E-R diagram ready, all the better.
When designing a database from scratch, we insist that it is difficult to predict the optimal setup from the get-go. With this in mind, we choose reasonable defaults while following good database design principles. Even though a database's specification changes, from the beginning of the design we put in place structures such as primary keys, foreign key constraints, uniqueness constraints, auto-incremented columns, and atomicity, because these will be important even when the database inevitably changes. (If you don't know what these are, they're basically just ways that the database enforces rules that keeps itself neat and tidy.)
Benchmarking is a process that tests the limits of our database. Typically, it involves barraging the database with insane amounts of data, which can bring system performance to a crawl. This is done using tools such as ab, supersmack, or SysBench.
Once the system performance is brought to a crawl with an unreasonably high load, we analyze where it's slow, using standard profiling tools that come with the database.
Finally, when we know where the performance bottleneck is, we apply fixes such as adding appropriate table indexes, vertically partitioning tables, and rewriting queries.
