I think what's missing is something like "Data Model Patterns: A Metadata Map" by David C. Hay<p>It's like C. Alexander's "Pattern Language" but for data models.<p>> ...I was modeling the structure— the language —of a company, not just the structure of a database. How does the organization under-stand itself and how can I represent that so that we can discuss the information requirements?<p>> Thanks to this approach, I was able to go into a company in an industry about which I had little or no previous knowledge and, very quickly, to understand the underlying nature and issues of the organization—often better than most of the people who worked there. Part of that has been thanks to the types of questions data modeling forces me to ask and answer. More than that, I quickly discovered common patterns that apply to all industries.<p>> It soon became clear to me that what was important in doing my work efficiently was not conventions about syntax(notation) but rather conventions about semantics(meaning). ... I had discovered that nearly all commercial and governmental organizations— in nearly all industries —shared certain semantic structures, and understanding those structures made it very easy to understand quickly the semantics that were unique to each.<p>> The one industry that has not been properly addressed in this regard, however,is our own— information technology. ...<p><a href="https://www.goodreads.com/book/show/20479.Data_Model_Patterns" rel="nofollow">https://www.goodreads.com/book/show/20479.Data_Model_Pattern...</a><p>I've pushed this at every company/startup I've worked at for years now and nobody was interested. You can basically just extract the subset of models that cover your domain and you're good to go. Or you can reinvent those wheels over again, and probably miss stuff that is already in Hay's (meta-)models.
Two (more) things I'd like to point out:<p>Prolog clauses are the same <i>logical relations</i> as in the Relational Model of DBs. ( Cf. Datalog <a href="https://en.wikipedia.org/wiki/Datalog" rel="nofollow">https://en.wikipedia.org/wiki/Datalog</a> )<p>The next big thing IMO is <i>categorical</i> databases. Go get your mind blown by CQL: <a href="https://www.categoricaldata.net/" rel="nofollow">https://www.categoricaldata.net/</a> It's "an open-source implementation of the data migration sketch from" the book "Seven Sketches in Compositionality: An Invitation to Applied Category Theory" which went by yesterday here: <a href="https://news.ycombinator.com/item?id=20376325" rel="nofollow">https://news.ycombinator.com/item?id=20376325</a><p>> The open-source Categorical Query Language (CQL) and integrated development environment (IDE) performs data-related tasks — such as querying, combining, migrating, and evolving databases — using category theory, ...
When designing data structures that hold my program's state, my structures tend to become more coupled& brittle because I use them in multiple contexts and do a poor job of separating them, I want each context to have the perfect shape for each context even if they share data<p>It makes me wonder what happens if instead of creating a tree of data I put my data into a Datom flat data structure then used syntax like Datalog to conform data into shape for each new context<p>Unfortunately, I still haven't installed Datomic free to try this out because I feel dirty if it doesn't come from brew
As someone who works in data warehousing and business intelligence I always feel the pain of developers thinking of data as an afterthought. Biggest issues are always not all data is persisted and not all changes are tracked in the database. The means you can never do all the reports the business want and it is always a mission to explain to business that you cannot report off data that doesn't exist or not properly stored (referential integrity). My dream has always been one day developers will think of the data first :-).
I've skimmed over the book and I think it <i>definitely</i> needs more code examples and before and afters, because whatever little code I saw is unconvincing.<p>In fact, when developing I don't want to think too much about mere <i>data</i>, I want to see the algorithms and data structures and even the overall program logic. Having to worry about each individual struct member, and whether those are used properly and kept in sync is a pain and is throwing away the brilliant idea of encapsulation.<p>The chapter on "managers" reads like a caricature of poor OOP practices, I don't quite understand how it's become a best practice in data-oriented design :)<p>All in all, this seems like a clumsy way of designing things.
I got this book recently in print form, its from a gamedev perspective partially, but interestingly a lot of the book will be familiar to people who work with databases, and thus a lot of the webdev world. A lot of the ideas come from how we organize data in databases and applying that to data in your code.
This is exactly the wrong design pattern to follow. Translation from code to business model has always been problematic. Reducing that translation by modeling code after a business domain (not a business object) is the best way to reduce complexity and enable a longer life for a system.
If you are interested in tools for automatizing Data-Oriented design. Check out GeneXus. You design what the user needs from the data, and it automagically builds the normalized tables, the cruds in various languagages and deploys.
I attempted to read the first section expecting that this is something that reduces the complexity of software design, and I'm completely lost here. They don't really explain what <i>is</i> data-oriented design in a single summed up paragraph. So I turned to Wikipedia and I found this:<p><pre><code> In computing, data-oriented design is a program optimization approach motivated by efficient usage of the CPU cache, used in video game development.
</code></pre>
???
The Pure Function Pipeline Data Flow,
based on the philosophy of Taoism and the Great Unification Theory,
In the computer field, for the first time,
it was realized that the unification of hardware engineering and
software engineering on the logical model.
It has been extended from `Lisp language-level code and data unification` to `system engineering-level software and hardware unification`.
Whether it is the appearance of the code or the runtime mechanism,
it is highly consistent with the integrated circuit system.
It has also been widely unified with other disciplines (such as management, large industrial assembly lines, water conservancy projects, power engineering, etc.).
It's also very simple and clear, and the support for concurrency, parallelism, and distribution is simple and natural.<p>There are only five basic components:<p>1. Pipeline (pure function)<p>2. Branch<p>3. Reflow (feedback, whirlpool, recursion)<p>4. Shunt (concurrent, parallel)<p>5. Confluence.<p>The whole system consists of five basic components.
It perfectly achieves unity and simplicity.It must be the ultimate programming methodology.<p>This method has been applied to 100,000 lines of code-level pure clojure project, which can prove the practicability of this method.<p>[The Pure Function Pipeline Data Flow](<a href="https://github.com/linpengcheng/PurefunctionPipelineDataflow" rel="nofollow">https://github.com/linpengcheng/PurefunctionPipelineDataflow</a>)