2

I was wandering if there exists some kind of database that organises data based on some declared type rather than tables or collections.

I'll try to explain better with an example. Let's say I have the following types:

Named {
  name: String!
}

Priced {
  price: Number!
}

TimePeriod {
  from: Date!
  to: Date!
}

Event is Named, Priced {
  dates: [TimePeriod]
}

News is Named {
  category: String!
}

Course is TimePeriod, Named, Priced {}

Now I put in the DB the following data:

[
  {
    from: "2019-12-12",
    to: "2019-12-13",
    name: "This is Timed and Named"
  },
  {
    from: "2019-12-12",
    to: "2019-12-13",
    category: "Weird Stuff",
    name: "This is a News, Timed and Named"
  },
  {
    name: "This is just Named",
    category: "Useless Cat."
  },
  {
    name: "This is an Event, Named and Priced",
    dates: [],
    price: 15
  },
  {
    name: "This is an Event, Named, Priced and TimePeriod",
    dates: [{
      from: "2019-12-12",
      to: "2019-12-13"
    }],
    price: 15
  },
  {
    name: "This is a Course, Named, Priced and TimePeriod",
    from: "2019-12-12",
    to: "2019-12-13",
    price: 15
  }
]

The queries I'd like to have could be like:

FIND TimePeriod WHERE from > Date.now()
FIND TimePeriod, Named WHERE name = "This is%"
...

Basically the idea is not having tables or collections, but defining types the data might or might not fit with, then you query using those types to retrieve only the data that fits with all the types you ask for in your query and match the requirements on the declared fields of any of the given types.

I feel like there should be something like this around or this could be achieved somehow with existing DBs but I can't figure out how. Any hint would be great. Thanks.


Possible Use Cases

I was wandering about such a kind of DB as a hypothetical idea, but it might be useful for the following use cases I'd like to implement for a personal home automation/information system.

Let's say I have a mixed and various array of data sources such as:

  • Some incoming Webhook event from various services
  • Data sent from various devices/sensors at home
  • Data from feeds
  • Data sent from various apps
  • ... any other source that might pop up in the future ...

Then I have a series of mixed consumers of those data as well such as:

  • Data visualisation dashboards
  • Calendars
  • ToDo List apps
  • Devices listening for commands/configurations
  • Chats/notification systems
  • Some outgoing Webhook to trigger other services
  • ... any other consumer that might pop up in the future ...

Now the consumers don't really care about what a specific piece of data is itself, but they're concerned about what can be done with it. For example, in a calendar, I don't really need to know what a piece of data is as long as it has a date and a title I can place it, so I could place on a calendar:

  • Command events
  • Due dates from a Trello board
  • Vacation days
  • Planned grocery store shopping
  • Critical events from some home device
  • ... any other data with a date and a title ...

This could also be useful for:

  • TODO Lists: anything goes as long as it requires some kind of action from me
  • Notifications: any event could be notified as long as it has a title, a description an like a severity or something.
  • Spending Plans: anything that has a cash flow associated with it and a date can be used to display monthly cash flows and balances etc.
  • Contacts: anything with a name and an email goes for a contact.
  • Web Bookmarks: anything with an URL and a title can be bookmarked.
  • Places on the map: anything with coordinates can be directed to.

So the architecture of the system could be:

  • A receiver that receives data form various sources and stores it in the DB (eventually mapping field names if needed)
  • The DB with a single collection of anything
  • An array of observers registered to a specific data type based on their need.

Now if I add a piece of data for example about an appointment I got with a Company for a Job Interview, I add the whole blob of data in the DB and I'd get:

  • The date of the interview on my Calendar with "Occupied" status for that day
  • A TODO in my TODO app
  • A notification the day before
  • A Bookmark with the link to their website
  • A place in my maps to start navigation
  • A contact in my address book with info to contact them
  • A trigger to a IG post that says "Going to get a job!"
  • ... whatever I'd like to as an answer for the new data...

I don't know if this makes sense, I figured out I could do something like this by creating a MongoDB database with a single collection of "everything" and then querying it based on attributes like { name: { $exists: true, $type: string, $eq: **some query** }, ... }, but it doesn't feel quite natural.

Basically the features I'd like to have by design would be:

  • Some attribute consistency check: if I add a piece of data with due of type Date then, adding a new piece of data with attribute due of type Boolean should give error in order to keep the consuming end consistent. Namespaces could be used to differentiate attributes.
  • An attribute dictionary with names and types of the attributes and the possibility to specify descriptions to focus the usage of the attribute.
  • Type builders, some sort of attribute grouping system to define types for the "find" queries. At the same time the ability to specify a new type at query time.
  • "Auto-casting": it would be nice if any retrieved piece of data could be automatically casted to the most specific type available in the DB definitions. For example I have a Timed type with a dateTime field, and a Todo type which is Timed and has a status, it would be nice when I query for Timed items that those piece of data with a status are actually instances of Todo so I can add extra triggers/UI/UX etc. on them.
4
  • 1
    Do you have a real world use case for such a data store? Or is this just a purely hypothetical idea?
    – Doc Brown
    Sep 29, 2019 at 18:45
  • @DocBrown thanks I added them to the question. Sep 30, 2019 at 12:25
  • 1
    Not exactly what you're looking for, but most SQL databases support user-defined types Sep 30, 2019 at 13:10
  • 1
    I think you need to research for NoSQL databases. They typically have quite different ideas how to organize their data. But at least they should have encountered and eliminated some of the pitfalls of a new data structuring. Like redundant storing of data via different paths and then altering the data.
    – Joop Eggen
    Sep 30, 2019 at 15:46

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.