1

I'm working on a system where each user defines a strongly typed definition of data they can store, consisting of classes with specified fields. Embedded classes are also supported. My first instinct was that NoSQL would be perfect for this, because we wouldn't have to worry about keeping track of changes to the data types. Because MongoDB only supports sharding based on indexes, I thought it would make sense to put everything in a single collection, sharded by user_id. However, we now have to implement sorting/filtering on the data. Ideally we want to dynamically create indexes based on common user query patterns. A single collection doesn't sound great for this, and MongoDB only supports 64 indexes per collection anyways.

Now I am thinking that maybe we should create a PostgreSQL table per user. The relational aspect of this will be helpful to expose queries across class relationships to users. However, I'm not sure how well a large number of tables will scale. I can't seem to find any resources related to sharding by table, vs. by a field.

Does the table per user make sense, or maybe there's another way to architecture this I haven't thought of? How would sharding work?

Improve this question
4
  • So if I understand you correctly, you're building an application that allows the end users to create their own classes that you need to store data for?...how will these classes / objects be used after they're created? Is there going to be any business logic behind them, or they're simply going to be used to represent a kind of visual / virtual relationship for the end user, but not be very functional outside of that? Understanding your application use cases may help us provide a better direction for you to head towards.
    – J.D.
    Commented Feb 19, 2022 at 2:59
  • Users create a strongly typed schema defining data they can store. They can create instances of the datatypes they define and store them. The main logic is in querying that data, sorting, filtering, and viewing that data in different ways.
    – I_A
    Commented Feb 19, 2022 at 3:09
  • Gotcha, so your app will give them the ability to design a schema, relationships, etc, and store data in a database structured to that schema, and the data can be recalled and displayed to the end user, but you're not going to actually instantiate concrete objects that represent that schema and put functional logic behind those objects, in the application layer, correct? This will basically be CRUD operations to the end user with them designing the schema to store the data that they'll be CRUDing?
    – J.D.
    Commented Feb 19, 2022 at 4:30
  • 1
    Yes, that's exactly right.
    – I_A
    Commented Feb 19, 2022 at 4:34

1 Answer 1

Reset to default
-1

try schemafreesql. auto indexing, schemaless, no tables to create.sql like language and aggregate functions and a sql like query language

Classless schemaless Object store. stores deeply nested object structures. can handle any number of attributes. No schemas easily modify data structures.Not a document store creates objects from json docs, any object can reference any object.

Integrates with various SQL backends

Improve this answer
1
  • just to clarify the object instances that the users creat are stored the classes that the users create are NOT coupled with the schemaless object store its not an ORM
    – eric
    Commented Mar 2, 2022 at 3:38

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.