-2

Here's the issue I'm having in moving from SQL to a document db with a 2MB limit on documents. Suppose I have an entities that looks like this

unit
   id
   item[]

item
   id
   name

If item[] can be arbitrary length (as is usually the case), then I can't store the unit in its literal representation because there's a chance that its size could exceed 2MB. What I think I have to do in such a case is convert this structure to

unit
   id

item
   id
   unitId
   name

and then need to perform "joins," which feels too much like SQL (Hence, what's the point of using no-SQL?).

See Sharp
  • 379
  • 1
  • 4
  • 11
  • 2
    If you need relations enforced by the database, you will probably need a *relational* database :) – juunas Oct 29 '18 at 13:56
  • 2
    "what's the point of using no-SQL?" - exactly. Modern relational databases can handle most tasks you throw at them. Why abandon a perfectly working tool? :shrug: – Sergio Tulentsev Oct 29 '18 at 13:56

1 Answers1

-3

this is more of a architecture question than of a development one, but here's the deal: Plan your data based on 3 levels, where

  • level one, represents micro data, such as a person and his two addresses.
  • The level 2 represents mid-sized lists, such as all the sales a store performed on a single day
  • level 3 are the huge lists with billions of itens

the idea is that for cases 1 and 2 you can very much store that info nested on the entity, without any issues on a foreseeable future (remember that 2MB doc is a very long document, with over 2 million chars) and this means no joins! on a heavily used system, this can mean huge savings!

I'd suggest that you study your data, plan it's behavior and see if you do need to break it apart

Leonardo
  • 10,737
  • 10
  • 62
  • 155