6 ms·

"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll b

"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious." - Fred Brooks, The Mythical Man Month.

mannykannot 10y ago
I have seen at least one case where I could ascribe no meaning to several of the tables in a database. To be fair, seeing the code did not help either, until it became apparent that it was all an attempt to work around a fundamental error. The creator of this mess was blaming the users for it not working, and I was happy to refute that claim and exonerate the users.
vog 10y ago
Note that "tables" in this statement had a different meaning than today. That one wasn't about relational databases, it was about tables as in-memory data structures. In today's words, "flowcharts" means "code" and "tables" means "data structures". I don't care if it is: - tables in a relational database - nested structs (records) and lists - nested dictionaries (hash tables) and lists - JSON - XML - ... whatever What I do care is that I can see the data structures, and not just the code. Static typing often gets that job done fairly well. If you don't use that, please use at least type annotations. This is the most important part of your documetation, and the compiler ensures it remains correct over time. Most of the time, this (+ the function name) is the only documentation I really need.
- deleted 10y ago
  [deleted]
scarface74 10y ago
Show me your well structured code and well named unit tests and I won't need your flow charts. Show me your well defined normalized tables and I have all I need. But for the love of $entity please don't show me tons of business logic in stored procedures. I actually won't work for a company that expects me to build or maintain a product based on stored procs.
- cafard 10y ago
  Show me your well-defined normalized tables, and I will know the rules for a valid state of the system. How, though, will I know the rules for a valid transition from one state to another? Have I seen some nasty stored procedures? Yes, a number of which I have written. But I have seen well thought out and useful ones also.
  - scarface74 10y ago
    With logic being in code: * it is easily unit tested * all source code is one place that can be branched, versioned, merged, deployed, rolled back, diffed, code reviewed, approved with pull request etc.
    - adaml_623 10y ago
      Why are your stored procedures not in the code repo?
      - lmm 10y ago
        Because deployment tooling for stored procedures sucks?
        jamra 10y ago
        Stored procedures are easier to deploy than table schema. You just need to drop if exists and then create them. Table schema is the hard part since there is overhead associated with creating an index on an existing table and with renaming a column.
    - spacemanmatt 10y ago
      SQL is code. Not sure how that escapes people.
      - scarface74 10y ago
        Harder to unit test, harder to merge, harder to roll back...

mannykannot 10y ago

I have seen at least one case where I could ascribe no meaning to several of the tables in a database. To be fair, seeing the code did not help either, until it became apparent that it was all an attempt to work around a fundamental error. The creator of this mess was blaming the users for it not working, and I was happy to refute that claim and exonerate the users.

vog 10y ago

Note that "tables" in this statement had a different meaning than today. That one wasn't about relational databases, it was about tables as in-memory data structures. In today's words, "flowcharts" means "code" and "tables" means "data structures". I don't care if it is: - tables in a relational database - nested structs (records) and lists - nested dictionaries (hash tables) and lists - JSON - XML - ... whatever What I do care is that I can see the data structures, and not just the code. Static typing often gets that job done fairly well. If you don't use that, please use at least type annotations. This is the most important part of your documetation, and the compiler ensures it remains correct over time. Most of the time, this (+ the function name) is the only documentation I really need.

deleted 10y ago
[deleted]

scarface74 10y ago

Show me your well structured code and well named unit tests and I won't need your flow charts. Show me your well defined normalized tables and I have all I need. But for the love of $entity please don't show me tons of business logic in stored procedures. I actually won't work for a company that expects me to build or maintain a product based on stored procs.

cafard 10y ago
Show me your well-defined normalized tables, and I will know the rules for a valid state of the system. How, though, will I know the rules for a valid transition from one state to another? Have I seen some nasty stored procedures? Yes, a number of which I have written. But I have seen well thought out and useful ones also.
- scarface74 10y ago
  With logic being in code: * it is easily unit tested * all source code is one place that can be branched, versioned, merged, deployed, rolled back, diffed, code reviewed, approved with pull request etc.
  - adaml_623 10y ago
    Why are your stored procedures not in the code repo?
    - lmm 10y ago
      Because deployment tooling for stored procedures sucks?
      - jamra 10y ago
        Stored procedures are easier to deploy than table schema. You just need to drop if exists and then create them. Table schema is the hard part since there is overhead associated with creating an index on an existing table and with renaming a column.
  - spacemanmatt 10y ago
    SQL is code. Not sure how that escapes people.
    - scarface74 10y ago
      Harder to unit test, harder to merge, harder to roll back...