6 results found

1. Tool for score data model

   It would be great to have a tool which can scores a data model from a specific database. I mean, I could allows this tool to scan a database model and score this data model based on best practices, patterns and anti patterns. It could also generates a list of problems and suggestions for improvement.

   This tool could be used on CI pipelines near to the unit tests and the main goal is to avoid release new features using a bad data model.

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Data Models  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Extend schema validation to be able to enforce referential integrity between collections

   Where a relational database uses 2 tables to store a 1:many "parent - child" relationship between entities, MongoDB mostly stores the child documents in an array file as part of the parent document. This automatically ensures referential integrity in that
   - a child document cannot be inserted or updated to refer to a non-existent parent, and
   - a parent document cannot be deleted such that it leaves "orphaned" child documents

   However, there are situations where the number and/or size of the child documents makes embedding them all in their parent unworkable, due to the 16 megabyte document size limit if nothing else.

   In those cases, the documents are stored in separate collections, and schema validation cannot enforce the integrity of the references between them.

   Schema validation already permits rules to be specified as $expr expressions for rules based on multiple fields in the document being inserted/updated, like "totalCost = basePrice + taxAmount".

   One way this enhancement could be implemented is by extending the use of $expr to permit use of an aggregation pipeline that does a $lookup to the other collection.

   Where a relational database uses 2 tables to store a 1:many "parent - child" relationship between entities, MongoDB mostly stores the child documents in an array file as part of the parent document. This automatically ensures referential integrity in that
   - a child document cannot be inserted or updated to refer to a non-existent parent, and
   - a parent document cannot be deleted such that it leaves "orphaned" child documents

   However, there are situations where the number and/or size of the child documents makes embedding them all in their parent unworkable, due to the 16 megabyte document size limit if… more

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Data Models  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. UTF 16 and UTF 32 support

   Currently MongoDB only support UTF 8 strings but it will be great if there is a configuration to change UTF 16 or UTF 32.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Data Models  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. BSON::Proxy Proxy content from/to another collection

   I would like a mongodb data type, called

   BSON::Proxy # not indexable or searchable

   Which would hold the value of another collection & id.

   IE:

   BSON::Proxy({database: "this_one", collection: "blobs", _id: "123"})

   This would allow my code to request a field that would be used for reading ONLY IF REQUESTED in the projection.

   Example record:
   {
   id: "abc",
   username: "test user",
   blob: BSON::Proxy({database: "thisone", collection: "blobs", _id: "123"})
   age: 50
   }

   db.collection.find(query, projection, options)

   db.users.find({_id: "abc"}) # returns all fields except blob.

   db.users.find({_d: "abc", { _id: true, username: true, blob: true, age: true }}) # returns all fields including blob.

   This would allow me to store BLOBS with the document that are accessable only on demand and would not adversely affect performance
   when searching as the BLOB would not be loaded with the document

   Under the hood the BLOB would be stored in another collection tables.

   This maximizes scan and queries but allows for the simplification of a schema for storing large blocks of data.

   No FK validation would be expected.

   I would like a mongodb data type, called

   BSON::Proxy # not indexable or searchable

   Which would hold the value of another collection & id.

   IE:

   BSON::Proxy({database: "this_one", collection: "blobs", _id: "123"})

   This would allow my code to request a field that would be used for reading ONLY IF REQUESTED in the projection.

   Example record:
   {
   id: "abc",
   username: "test user",
   blob: BSON::Proxy({database: "thisone", collection: "blobs", _id: "123"})
   age: 50
   }

   db.collection.find(query, projection, options)

   db.users.find({_id: "abc"}) # returns all fields except blob.

   db.users.find({_d: "abc", { _id: true, username: true, blob: true, age: true }}) # returns all fields including blob.

   … more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Data Models  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Support readOnly in Json Schema Validation

   Support the readOnly property for json schema validation to make certain fields immutable (or the entire document) after creation.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Data Models  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Change how document size is calculated

   Disclaimer: I'm aware that this is a pretty big feature request.

   Currently a document has a max size of 16 mb. I'm not suggesting changing that. However, I'm suggesting changing how that size is calculated.

   I'm designing a database in which documents have a tree structure. The document will have an array called "nodes", which can hold any number of child nodes. Those nodes can also have arrays of nodes, and so on. It's a simple tree structure.

   For major users of my application, that outer document could get pretty big. It's not a problem right now (no users, no problems) but if my app goes big time I'd have to do a major overhaul to how I structure those hierarchies. Yes, I could design it like that from the get go, but the hierarchical structure is so easy and simple that, for now, I'm going with it.

   Now, here's what I'm proposing:

   Instead of internally storing each hash as a structure within a document or within another hash, store it as a reference to that hash. To the programmer it would look the same. However, the size of the document would only be based on the sizes of the references to the hashes, not the size of the hashes themselves. So the document, and its nested hashes, does not contain all the nested hashes, but only the their references. The document could be effectively much bigger because references don't take up much space.

   I throw the topic out for discussion.

   Disclaimer: I'm aware that this is a pretty big feature request.

   Currently a document has a max size of 16 mb. I'm not suggesting changing that. However, I'm suggesting changing how that size is calculated.

   I'm designing a database in which documents have a tree structure. The document will have an array called "nodes", which can hold any number of child nodes. Those nodes can also have arrays of nodes, and so on. It's a simple tree structure.

   For major users of my application, that outer document could get pretty big. It's not a problem right now (no users, no… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Data Models  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close