Has anyone wired up a complete, functional, entity-relationship diagram as a relational database with prototypes as tables and attributes as fields, organized and linked with primary and foreign keys(attributes) in their respective prototypes(tables)? Or is this just a fever-dream that I am experiencing? Is Tinderbox the tool for this, or should I be looking at Notion or something else?
If youâre looking to draw a diagram depicting a relational database, have a look at the OmniGroupâs OmniGraffle which has so called âstencilsâ for such diagrams. However, I am not sure you want to draw them by hand, so Iâm not sure whether I understood you correctly.
Are you trying to make a database or to represent the structure of one?
Given that underneath everything Tinderbox is a hypertext notation tool, is that a good base on which to build a relational database. In context, one can paint using Excel, using each cell like a coloured pixel, but is it the most suitable tool.
My sense is that assuming you do built it, which likely you canâat least as a facsimile, youâll then be seeking more powerful querying features Tinderbox doesnât have and likely wonât get (e.g. SQL). IOW, you may be starting a quest that ends disappointingly in terms of how well it then functions as an RDMS compared to d/b design as such from the outset.
But if itâs just a hobbyist projectâlike building the Eye of Sauron in Lego but out of generic bricksâthen doubtless it is worth a try.
Sorry, but I donât understand what your trying to do.
Thanks to each of you for your responses. But from the misunderstanding by a couple and a warning from another, I take it that Tinderbox is not the tool to implement the content of an already drawn entity-relationship-diagram for a Relational Database. I think the prototypes replicating tables and attributes replicating fields could work in principle, but the query aspect (SQL) would make this approach unusable. It seems I would be better off looking at Notion, or AFFiNE, or AnyType, or Capacities, or even Obsidian as a more functional approach. What i am really looking for is a tool that handles types (âis aâ book, or âis anâ author, or "is a " something else), with each type having distinct properties (with selected properties being wikilinkable to another typeâs properties), and the text part of the typeâs record a fully-functional outliner text editor natively handling foldable (collapsable) bullet lists and LaTex. As powerful as Tinderbox is with its stamps, action code, and scripting language, I am sadly realizing that Tinderbox is not for me for this particular type of application.
Thatâs an interesting problem, but it does not (to me!) sound like a relational database
I doubt Notion or Obsidian get give you much closer to this goal than youâd be simply by firing up an IDE.
a fully-functional outliner text editor natively handling foldable (collapsable) bullet lists and LaTeX
Well, natively is doing a lot of work. We have a native outliner, but its text editor does not support foldable lists, and while the HTML export system can manage LaTeX, thatâs not exactly native, either. Neither Obsidian nor Notion have native text editors, as I recall.
This sounds like prototypes to me. Not sure what Iâm missing,
Iâve done this in the past using templates and JavaScript that made my lists collapsible in preview. Depending on how develop your template, the bullets can take any number of syntax, e.g., asterics, LaTeX, HTML, etc. You can have Tinderbox calling any number of different lists.
It would be helpful to understand the purpose of the exercise/what you were looking to accomplish.
You can build these requirements with Tana. (A year-old example â the 2025 feature set is already far beyond the portrayed case.)
I did something like this, though I started in Tinderbox and moved to a database (Postgres) when things became a bit unwieldy on the map.
I had person, tv show and film as prototypes. A person could be an actor in, a writer of, a producer of, a director of, a tv show or a film. A personâs relationship to a tv show or film was expressed using named links.
It was fun, but I donât think Tinderbox wants to hold you to the kind of stringent rules that are described by, e.g. foreign keys. I think it could, though I couldnât tell you where to start, manage some elements but, taking an update rule on a foreign key relationship as an example, I donât believe Tinderbox can be coded to cascade an update of text in one note to another. Others may respond with the facts on that.
May I suggest you look at the PHP content management framework Processwire(.com)? This is a tool that you could use to emulate a database but, having said that, youâd be building a database on top of a database. The advantage youâd have with Processwire is that a lot of the work wrt to rich or other text fields is done for you. I wonât go into that any further, you can look it up. Itâs an excellent piece of software.
I think you might be better off converting your model into a physical db on, e.g. Postgres, which runs very well on macOS (installers from EDB) and, well, thats all Iâve got for you!!
Since youâve created a model, I suspect you may know all that so forgive me if Iâve seemed to be âteachingâ. Not my intention. Iâd be happy to talk to you about it though because I love this sort of problem.
Nic
It actually can, there are many methods to do something like this. Canât really provide a suggestion, however, without a concrete use case.
Why not simply use a real relational database instead of trying to build one in Tinderbox?
Have you had a look at NEO4J. It is a fully functional Graph database, where instead of using joins, you create links between nodes. So you could easily represent Persons, Authors, Books, Genres, and then Person A IS_AN Author, WROTE_A Book, etc. Once you have defined the relationship between the nodes it can display it visually.
Dear GeeSkay,
Thank you for the information about NEO4J.
I tried downloading it right away.
I have not read whole guide very well,
How does NEO4J work?
I have not been able to figure it out yet.
I am using exactly org-roam & org-roam-ui in Emacs to implement a similar display.
But, currently considering a full migration from my Emacs environment to Tinderbox.
If you do not mind, could you tell me how you use it for?
Is it possible for you to provide an example of your setup on this site?
Yours, WAKAMATSU
Hi Wakamatsu,
I was involved in a project at work where NEO4J is being implemented to model our network inventory. Unfortunately I canât share any more information than that due to confidentiality reasons.
I havenât used it myself for a personal project yet, but I thought it would fit your scenario based on your comment. It is really another type of database, not a complete end user system. Although, with the built-in visualisations, you could get close.
Did you install the sample database available from their site? I think itâs the one with Actors and Movies. Iâd suggest exploring that and reading up on the Cypher query language to help you understand how to add, update, and retrieve data.
I have not but it actually seems straightforward albeit daunting. TB can also be used for flow processing as well. It would be interesting to add a UML output concept that could take mind mapping as input. Brilliant idea!
Given that there are lots of UML/concept map apps out there, what does Tinderbox do for that activity that existing apps donât? Or, is this more a case of wanting to use one app for a host of different tasks (normally done in discrete apps)? I ask out of genuine interest.
I guess Iâm confused by what is meant by ârelational databaseâ in this thread. The above description sounds like using prototypes and attribute values joined by action code.
A relational database structures data into tables and rows and is queried by tools like SQL.
Tinderbox does this; the âtablesâ are notes that can be structured via their attribute value similarities, one of the most obvious being $Prototype or $Type. The values within a note, i.e., a âtableâ or ârowâ recorded, can then be queried with any number of different operations and displayed with templates.
Tinderbox is a standalone, offline tool, and as such lacks collaboration and external access that a cloud or hosted database would have. Also, the approach to working with the data and visualizing it would require different mechanics. Outside of that, I go back to the different question, what does a ârelational databaseâ have that Tinderbox could not execute (albeit with a different paradigm)?
What TB does it do vs what it doesnât do (or well). This is the swiss army knife vs bayonet question to me. There are plenty of UML tools out there and they are excellent at what they do. However TB has always had the ability to tailor to your needs and allow refinement as needed. UML tools tend to follow a âwaterfallâ approach from my experience. Needs, design, blah blah blah.
UML/SQL/Data Design apps do not respond well to unknown/unknown discovery and adaption. They are not very good at known/unknowns either. They generally expect a set of knowns/knows and unknown/knowns.
On the other hand, TB is adaptability to its core.
Not to get too loopy but music is just different sounds, organized over a timeline. Notes (text) organized in different outputs result in, books, website, KM, research blah blah blah. The output, target or whatever you want to call it provides useful context and organization to the input.
Tinderbox has always been a personal app. and as such most of its output is meant to be shared. Increasing the ease and output options provides additional audiences.
I do alot of Project management, Meetings notes, agendas, task lists, project status etc. are all different outputs to a base set of data. Not all notes are used all the time but the ability to capture everything and spit it out as needed is very useful.
To me Data Design is one of those domains where TB can help figure that which needs to be figured out.
Now, if this does not make money, no point
This looks like an (entirely unsurprising) reflection of Tinderboxâs support for incremental formalism and easy structural do-overâat least when compared to formal process apps.
For things like concept maps, if there is a target output format (UML whatever) then Tinderbox ought to be able to export such data via custom templates. I do suspect a challenge will be the target app (i.e. within some formal domain) may not like essentially partial data that we might export. Feeding the limits of the target tool/format will likely drag that formalism into Tinderbox thus removing the flexibility we enjoy.
This isnât to argue the last post, but Iâm wondering what output for might give âenoughâ structure for other purposes (i.e. be importable) and we can then look tat if it is exportable via Tinderbox and importantly whether doing that imposes undue restrictions on how the user works within Tinderbox.
The concept of templates provides a âuniversal output driverâ but they tend to get cluttered with things to make output more presentable. I am wondering if an intermediate step would help. Think of a template of templates. Maybe this is doable today. A more primitive set of templates that transfer the elements that can be consumed by multiple output presentations. This would be more along the MCV approach. The view is the final output. The controller notes, agents, structure. Its kinda like composites I think but with an additional option/step to point the output to A or B.
The final output would be the View.