5 ms·

Great post. I find that many front end developers start with the User Design first, ignoring how the data should be stored or accessed. While user centricity

Great post. I find that many front end developers start with the User Design first, ignoring how the data should be stored or accessed. While user centricity is a great value, if you worry about screens needed rather than data needed, you cause trouble down the road. I've found that a data-first mental model is much more scalable and supportable. Many times the details of the databases get abstracted away, and performance suffers.

prashnts 10y ago
But, aren't they frontend developers, and not the Backend developers?
- mathattack 10y ago
  It helps to have a broad view so you can plan and design accordingly. Back end developers should understand how people use the system, even if they're not going to own the designs. Similarly, to be great programmers, front end developers need an understanding of what goes on underneath the hood, even if it's not their day job. (I understand it's all part of the learning curve) The extreme of this is Joel's [0] exhortation that every programmer should learn C. It's a different context, but the same principle. [0] http://www.joelonsoftware.com/articles/CollegeAdvice.html http://www.joelonsoftware.com/articles/CollegeAdvice.html
lloyd-christmas 10y ago
> I find that many front end developers start with the User Design first, ignoring how the data should be stored or accessed This sentence seems contradictory. If you start with user design, you then know how the data will be accessed which allows you to store it with purpose. Obviously this shouldn't be at the expense of proper database design, but how your app functions defines how you should store your data. While not directly screen-by-screen design, one example I always see is that people default to creating an Address table. Many apps never store more than one address per user. If it's one-to-one, why force a join? (I think this is more of an overlap of both of our views though, and it popped into my head because Address tables are a pet-peeve)
- developer2 10y ago
  >> how your app functions defines how you should store your data I think this is the fallacy the parent you are replying to is attacking. Your data should stand apart from your application. Applications change over time. Many databases also serve multiple applications (web, mobile, api, stats, etc.). Your data store should make sense on its own without being tied to an application's design. If you build your database according to your application, then making changes to the application can be difficult or require refactoring the database to match the new application specs. If you instead build your database to make sense standalone, it's up to each application to use it appropriately.
  - lloyd-christmas 10y ago
    > Many databases also serve multiple applications... Your data store should make sense on its own without being tied to an application's design. While your point is valid, I think it's theory vs. practice. I think most databases don't get used for wildly different applications. I'd rather design my database for something that I know is performance-sensitive than design it for an imaginary application that might exist in the future. I've never experienced a case where our application changes dramatically enough that manipulating your database is anything serious enough to write home about. If you previously only had a shipping address and now you need a billing address as well, it's a pretty straightforward migration. Incremental change isn't hard. Companies that become Medco are few and far between. Their database should default modeling one-to-one relationships as one-to-many just so someone might be able to use it more generically in the future. But that's because it's a realistic use-case. My point was that there is a balance to be had between stand-alone and real-life usage, and you shouldn't default to full generic just to make it stand-alone.
    - mathattack 10y ago
      While your point is valid, I think it's theory vs. practice. I think most databases don't get used for wildly different applications. I'd rather design my database for something that I know is performance-sensitive than design it for an imaginary application that might exist in the future. Reminds me of the cynical saying for data warehouses, "Data in, but never out." :-) What I have seen frequently enough is myopic data designs hurting flexibility later. For example - assuming 2 level customer relationships (Corporate parent and individual store) with things like regions appearing at tags, rather than flexible hierarchies. The assumptions behind this then gets built into the code base, and fixing it requires more than just a database update. (And even if you fix the database, you are missing the historical hierarchies)

prashnts 10y ago

But, aren't they frontend developers, and not the Backend developers?

mathattack 10y ago
It helps to have a broad view so you can plan and design accordingly. Back end developers should understand how people use the system, even if they're not going to own the designs. Similarly, to be great programmers, front end developers need an understanding of what goes on underneath the hood, even if it's not their day job. (I understand it's all part of the learning curve) The extreme of this is Joel's [0] exhortation that every programmer should learn C. It's a different context, but the same principle. [0] http://www.joelonsoftware.com/articles/CollegeAdvice.html http://www.joelonsoftware.com/articles/CollegeAdvice.html

lloyd-christmas 10y ago

> I find that many front end developers start with the User Design first, ignoring how the data should be stored or accessed This sentence seems contradictory. If you start with user design, you then know how the data will be accessed which allows you to store it with purpose. Obviously this shouldn't be at the expense of proper database design, but how your app functions defines how you should store your data. While not directly screen-by-screen design, one example I always see is that people default to creating an Address table. Many apps never store more than one address per user. If it's one-to-one, why force a join? (I think this is more of an overlap of both of our views though, and it popped into my head because Address tables are a pet-peeve)

developer2 10y ago
>> how your app functions defines how you should store your data I think this is the fallacy the parent you are replying to is attacking. Your data should stand apart from your application. Applications change over time. Many databases also serve multiple applications (web, mobile, api, stats, etc.). Your data store should make sense on its own without being tied to an application's design. If you build your database according to your application, then making changes to the application can be difficult or require refactoring the database to match the new application specs. If you instead build your database to make sense standalone, it's up to each application to use it appropriately.
- lloyd-christmas 10y ago
  > Many databases also serve multiple applications... Your data store should make sense on its own without being tied to an application's design. While your point is valid, I think it's theory vs. practice. I think most databases don't get used for wildly different applications. I'd rather design my database for something that I know is performance-sensitive than design it for an imaginary application that might exist in the future. I've never experienced a case where our application changes dramatically enough that manipulating your database is anything serious enough to write home about. If you previously only had a shipping address and now you need a billing address as well, it's a pretty straightforward migration. Incremental change isn't hard. Companies that become Medco are few and far between. Their database should default modeling one-to-one relationships as one-to-many just so someone might be able to use it more generically in the future. But that's because it's a realistic use-case. My point was that there is a balance to be had between stand-alone and real-life usage, and you shouldn't default to full generic just to make it stand-alone.
  - mathattack 10y ago
    While your point is valid, I think it's theory vs. practice. I think most databases don't get used for wildly different applications. I'd rather design my database for something that I know is performance-sensitive than design it for an imaginary application that might exist in the future. Reminds me of the cynical saying for data warehouses, "Data in, but never out." :-) What I have seen frequently enough is myopic data designs hurting flexibility later. For example - assuming 2 level customer relationships (Corporate parent and individual store) with things like regions appearing at tags, rather than flexible hierarchies. The assumptions behind this then gets built into the code base, and fixing it requires more than just a database update. (And even if you fix the database, you are missing the historical hierarchies)