Hot answers tagged

31

While I agree with your premise that NoSQL is not a panacea for all database woes, I think you misunderstand one key point. In NoSQL database you have only one criterion you can search for effectively - the key. This is clearly not true. For example MongoDB supports indices. (from https://docs.mongodb.org/v3.0/core/indexes-introduction/) Indexes ...


14

No, it is not a code smell by itself. Data might very well be this complex - but we have no way of knowing if it is in your case. If you have too many joins to handle, you can use views to introduction abstraction. You are basically asking "my program has 10000 lines of code, is it too complex?" It depends on how complex a problem you are trying to solve! ...


13

In layman terms. Short answer: That many joins in a single query should be avoided. It smells so much that oportunistic predators would track it through the savanna for miles. Long answer: If the query selects just a few columns then it means that the 25+ joins where needed just to bring those few columns. It's an indicator of over-normalization or ...


5

It doesn't necessarily smell although it does if performance is a problem. Database complexity is a matter of the task at hand. Do you just need a key that represents the data in each table, use 3NF? Do you need relations to be split up more so that transitive relations are removed? Use 4NF. Is data in streams and certain attributes need to change ...


5

NoSQL databases have very little to do with “No SQL”. They are about admitting that you can’t have a database at scale that is always consistent and supports complex transactions and has durability. In a normal relational database all indexes are automatically kept updated within the scope of a transaction, so can be used for any query. In a NoSQL ...


2

You're making some assumptions that aren't correct. Mysql doesn't store the rows at the end of table: rows are stored where there's space. It can be at the end, but can also be in the middle, if routes were deleted. And retrieves in an order that may appear ordered. In your first query you're retrieving without ordering the results, and you may have ...


2

In this case, it doesn't look like it makes sense - the calculation is simple, quick and easily made in application code (or even in SQL). Adding the column means the storage for it is required, IO costs go up etc... Which is one cost/benefit analysis you need to make here. If the calculation were something highly CPU intensive, denormalizing as you ...


1

And that question goes for REST APIs in general -- when you write/make a REST API, are you just constructing a 1:1 mapping of your database? No. The database is just an implementation detail. You can write a bunch of resources that map directly to your domain objects, but that isn't particularly RESTful, in and of itself. REST isn't about the domain, ...


1

Yeah, that sucks. Now, it might not be the DB that sucks. It may be the absurd report that needs this much disparate data (which nobody will actually read). Or it may be that you had a sane DB, but is now being used in weird ways it was never intended. Or maybe your query is too complex and a simpler relation can get you what you want. Or the process that ...


1

Ratio is a derived column that can be calculated. Store the value in database only for performance reasons. If your queries are slow. Otherwise do not store the derived column in the database. If you are not going to store the value in the database, which seems the most reasonable in your case, I recommend the following two options: 1. If the calculation ...


1

To my mind it isn't really data that needs to be stored. If you did store it of course, there is the complication that the ratio would need to be re-calculated should any of the underlying values change. Whatever way you do this will be messy - be it with stored procedures or triggers etc. You don't say how this fits into the system overall but you could ...


1

It depends. A bit of redundancy is allowed if comes with measured performance benefits. And this is if and only if you really need that performance boost, aka if it's a bottleneck in your application. So is it really that difficult to compute the ratio in your code? In your specific example I don't feel like the additional redundancy is justifiable. In my ...


1

i will provide an answer based on the readme file of a custom SQL builder of mine (Dialect) (plain text follows, removed library-specific references) Requirements Support multiple DB vendors (eg. MySQL, PostgreSQL, SQLite, MS SQL / SQL Server, Oracle, DB2, .. ) Easily extended to new DBs ( prefereably through a, implementation-independent, config setting ...



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