New answers tagged

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, ...


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 ...


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 ...


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 ...


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! ...


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 ...


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

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 ...


0

I used to think query builders were GUI apps that allowed you to select tables and make joins graphically while generating SQL under the hood, but now I understand that you also call query builders the APIs that provide a way of not having to create pure SQL queries, so abstracting yourself of potential differences in SQL flavors. Using such query builders ...


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 ...


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 ...


0

In other languages such as C, Java, etc. the standards for representing whole and fractional numbers are different. In C and various programming languages, integers (INT() in SQL) are usually "packed" integer bit strings and floating point numbers (FLOAT()/DOUBLE() in SQL) are usually stored as IEEE-754/-854-compliant bit strings. DECIMAL() and ...


0

There is nothing wrong how you do it, however there is alternative way as well, by using versions, the table could look like this Customer - Model -Version - Price - Currency - RRP A - Z -1 - 120 - GBP - 220 A - Z -2 - 100 - GBP - 200 A - Z -3 - 90 - GBP - 180 The version can be ...


0

There are many answers already, but I just wanted to add my summary. Clearly NoSQL concept covers a variety of different approaches in organizing data on-disk, in-memory and exposing it via a query language (some are even SQL-like!). In my view the strength comes from this variety of systems so you can choose the best tool for the job. But still hopefully ...



Top 50 recent answers are included