Hot answers tagged

95

I can't tell you why it's a bad idea. I can tell you a bunch of reasons why a relational database is a good idea though. Remember that not everyone consults a dictionary for a definition. More times than not, a dictionary is used to find the correct spelling. This means you're not just finding a needle in a haystack, you are searching the haystack for ...


32

First, don't try to do anything clever with decimal numbers, because they'll spite you. REAL and DOUBLE PRECISION are inexact and may not properly represent what you put into them. NUMERIC is exact, but the right sequence of moves will run you out of precision and your implementation will break badly. Limiting moves to single ups and downs makes the whole ...


27

If you go with the key-value store (which offers you a more impoverished programming model) and it turns out you need more structure (in your case, say, adding a third language), or you need to do more complex queries involving joins, you'll spend a bunch of time reorganizing your keys, denormalizing your data, and/or looping over all the data to find what ...


14

Same answer from here https://stackoverflow.com/a/49956113/10608 Solution: make index a string (because strings, in essence, have infinite "arbitrary precision"). Or if you use an int, increment index by 100 instead of 1. The performance problem is this: there is no "in between" values between two sorted items. item index ----------------- gizmo ...


14

Basically: If you can represent your data in a form of a bunch of documents, MongoDB could be a good choice. If you would rather imagine your data as a bunch of interconnected tables, MongoDB may not be a good choice. Here are two examples which I find illustrative: A few years ago, I created a blog engine. Its purpose is to host blog articles, and for ...


13

In a database a shard is when you break up a set of data across multiple servers. So for example if you had users could you put those with a name starting with A-E on one, server, F - K on a second and so on. That way the load of dealing with the operations on those users will be broken up across several servers. The reason you want to do this is because it ...


13

I have seen people using a self-reference to refer to the previous (or next) value, but again, it seems like you would have to update a whole lot of other items in the list. Why? Say you take a linked-list table approach with columns (listID, itemID, nextItemID). Inserting a new item into a list costs one insert, and one modified row. Repositioning an ...


12

You need to separate the two concerns: ID generation: client must be able to generate a unique identifier in distributed system Security concern: client MUST have a valid user authentication token AND the authentication token is valid for the object being created/modified The solution to these two unfortunately are separate; but fortunately they are not ...


12

Some considerations: Choice of database: relational databases such as Mysql or Postgres are not necessarily harder to scale than MongoDB and such. In many cases it's quite the opposite. Here is a great comparison of different storage technologies: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis "Event-driven" architecture: You have a lot of ...


11

You have a number of options when representing a tree structure with MongoDB. Here are five "patterns" that you could apply (link to details at the end). The Child References pattern stores each tree node in a document; in addition to the tree node, document stores in an array the id(s) of the node’s children. The Parent References pattern stores each tree ...


11

MongoDB is a database. Elasticsearch is a search engine. Since their aims are different, they have different priorities. MongoDB is focused on storing data consistently with good performance and to support different access patterns. Elasticsearch is focused on building low-latency indexes for search specifically text search. MongoDB does have full-text ...


10

"but it seems like that would be quite inefficient" Did you measure that? Or is that just a guess? Don't make such assumptions without any proof. "20 to 50 items per list" Honestly, that is not "a whole lot of items", to me that sounds just very few. I suggest you stick to the "position column" approach (if that's the most simple implementation for ...


10

We may not be able to help you until you tell us what you intend to do with the app. Relational databases are good for certain things, and NoSQL databases are good for others. As someone once said to me here on SO: the relational part of a relational DB is far more optimized than some other parts It means you can use a relational database also if ...


10

Why are you using a non-relational database in this case? You said: When listing an event I have to manually join refs in order to show the actual properties of the employees and crews (such as name), it's a bit tedious but what worries me most is performance: and My biggest problem so far though is what I believe is known as deep querying [...


10

For a database this small, it's probably not going to make much difference for performance. A standard RDBMS isn't a terrible idea here because presumably, there should be far more reads than writes of a given entry. Performance doesn't seem to be a primary driver for this. Caching in the application layer also mitigates such concerns. The other ...


9

Each technology has its advantages. The advantages of relational databases is that the RDBMS does some things for you, like: Enforcing referential integrity ( not allowing the insertion of an invoice detail if the invoice it belongs to doesn't exist) Avoid redundancy: things are stored only once. Complex queries can be done with a declarative language (SQL)...


8

I see this question a lot. It always seems to be thought of as either/or. MongoDB is a great new tool. It's also sometimes seem as the shiny tool for everything and that can be a poor choice in my experience. I think the best combination is definitely BOTH and I would like to commend you for your approach of using mylsql for some parts, such as users, but ...


8

Your only(main - post edit) plus for mongo seems to be "So application developers straightaway can start writing the code" But this must be caused by your current development practices rather than the technology. I can create those tables in mssql just as quickly as in mongoDb. I assume that in your RDBMS work you have to push that work off to a DBA team ...


7

For example if I go on a run three times a week for 1 hour there will be 10'800 new records per week, now imagine this with 1000 active users for a year. Well, let's not imagine, but actually estimate the data growth. Imagine each GPS coordinate is stored in two 32-bits variables (largely enough; probably you don't need that much precision.) Three hours per ...


7

I'm exposing the backend id to the public What other means do you have to identify your entities when they're returned through a request? That's perfectly legitimate and safer than SSN or similar identifiers. That's what Todd is talking about - making identifications technology and entity neutral and he's right. Efficiency topic You can keep both ...


6

This is really a question of scale, and use case.. How many items do you expect in a list? If millions, i think gong the decimal route is the obvious one. If 6 then integers renumbering is the obvious choice. s Also the questions is how the lists or rearranged. If you are using a up and down arrows (moving up or down one slot at a time), the i would use ...


6

MongoDB models relationships by using references. To normalize data, store references between two documents to indicate a relationship between the data represented in each document. In general, use normalized data models: when embedding would result in duplication of data but would not provide sufficient read performance advantages to ...


6

This is simply the wrong question to be asking. "NoSQL" doesn't refer to a specific database, it refers to an entire superclass of databases including document databases, distributed key-value stores, graph databases, and object databases. Speed is generally the least important factor in making decisions about data storage, no matter what some people might ...


6

First, it scales well. When a MongoDB database is too frequented or too big for a single server, you can easily add more servers by creating a cluster or replica-set of multiple shards. It scales almost linearly. This doesn't work nearly as well with most relational databases. Take a look at MySQL's list of limitations when working as a cluster, for ...


6

Why is this the behavior in MongoDB? MongoDB documents are stored on the server in a binary format called BSON (short for "Binary JSON"), which is a JSON-like format that supports additional data types. The JSON format was designed to be human readable and derived supported data types and behaviour from JavaScript. BSON was designed as a binary data ...


6

You don't have to block the complete UI before the response comes back. You only have to disable the parts of the UI which allow to make another API call before the first one is processed completely (in an asynchronous operation, of course!). If that is feasible or not depends heavily on the UI, the features of your application and how they are tied to ...


5

First of all, DDD is really about creating a model where reading the code is like how the actual domain experts would be talking about the domain. Second, they way DDD describes an aggregate root, the child objects on the aggregate root are merely properties on the aggregate root itself, and you shouldn't be able to access the child elements directly, only ...


5

Could Vote, in this case be considered an "aggregate" and be deserving of its own repository and aggregate status? I think this might be the right answer. An aggregate should be a transactional consistency boundary. Is there a consistency requirement between votes on a match? The presents of a Vote collection on a Match aggregate would suggest that there ...


5

Bandwidth is cheap. Time is not. I would suggest that if you are selling your software that you have the process as automated as possible, asking as few questions as possible, and have it "just work". Given this, 20mb isn't a lot and you're really looking at 20 seconds or less for most broadband connections. at least in my country. Bundling the software ...


5

There is no such thing as noSQL. There is only a whole bunch of new database technologies with completely different philosophies and use-cases, and all they have in common are things they also have in common with SQL databases. That means when you plan a project and are unsure about the database technology, you need to evaluate each noSQL database ...


Only top voted, non community-wiki answers of a minimum length are eligible