Hot answers tagged

7

Your coworker's design is a well-known antipattern known as "entity-attribute-value". It looks really attractive at first due to its flexibility, but experienced developers know it's a very bad idea because it eliminates all of the advantages of using a relational database in the first place. When you have a (normal-style) table that describes the ...


4

"Best" is relative. Microservices do come with a performance penalty for some cases, which is offset by better scalability. It may seem like a paradox, but you need to make an individual operation slower in order to make it possible for the system to scale better. In your case, better scalability means you can't handle complex state changes between many ...


4

would it be a 'bad idea', to implement a policy/practice to always persist data and to always implement 'auto-updating' (if possible) created, updated and deleted properties? Persistence and auditability (not stated but implied) are valuable goals, and it is good to think in that direction for cases where you need them. That said, to answer your questions: ...


4

Let's take the example of a major ERP on the market: all the master data and most of the transaction data carry 4 fields: the author and the time stamp of the record creation and of the last record modification. all the critical field changes (it's customizable what is critical) are logged with the author of the change, the timestamp of the change, the ...


3

The reason why you often have a database for each micro-service, is in order to separate each part of the system. If you store everything in one database, you will (as mentioned by Michal Kosmulski) lose some scalability. But more importantly, each micro-service might be better off with some other form of storage. Some of your micro-services might be best ...


3

No, it is not too verbose. I'd say it's close to being a best practice. Having created and modified dates on a per record basis allows one to see how stale that particular data row is. Most systems I have encountered have data retention requirements. By having these dates, one can have a data purge process to keep only a certain amount of data in a ...


2

But a coworker said that in my design we would have to alter table every time we need to add new property (which I agree) I agree too. What's the issue exactly? When you add new features you sometimes have to modify the database. Sounds fair enough to me, I know how to deal with that easily. In his solution we wouldn't have to alter table at all in the ...


2

As with all things software, 'unlimited' merely means 'limited by the system, not the developer'. A 64-bit int would allow you to store 18446744073709551615 ticks. Precision vs Scale Now, this is where you get to trade precision for scale. If you use ticks=microseconds, you'll get just over 1/2 million years to play with. Milliseconds gives you 1/2 ...


1

I like your co-workers design better with a slight adjustment. Depending on the content of both propertyName and propertyValue, further decomposition might be better so you don't have redundant data. You'd then have either two tables: PropertyName (with Id and Name fields) GameProperty (the current propertyName would be idPropertyName instead, a foreign ...


1

It is bad practice to denormalize as you state. Depending on your search criteria, any one of the four tables could be chosen by the query optimization routine. If you are selecting on a package selected from a drop-down list, there should be no reason to add the packages table to the query as you can match the package_id in the package_durations table. ...


1

I want to be able to add, remove, and update: the users (especially their passwords/key-encrypting-keys), the groups, the data-encrypting keys, and the data. I think you can gain the required independence between entities by using a mixture of asymmetric and symmetric encryption. The data storage requirements are quite high but only little data need to be ...


1

The issue I have with the answer to the question you posted is that if you view the requirements of the OP for security, nowhere does it actually mention that each user must provide their own decryption keys. In fact the question even goes so far as to suggest that they explicitly do not want the users password to be a determination in the encryption of ...


1

I think most applications should have them. These values are more of a convenience for trouble-shooting and other support needs. Soft deletes have benefits as well, but you always have to include them in your query logic. Just because you can use them, they're not enough. Many auditing needs require more data and sophistication even beyond logging. ...


1

It sounds like you are digging around in the implementation details of a large product that (probably) is designed to be used via GUI's and APIs. In your position, I would be asking myself why I was doing this. Probably you would be better off not >>trying<< to understand. If you really need to know this kind of thing, then you are probably trying ...


1

Although its a 3 years old thread, still I'm replying it thinking that it might be helpful to somebody. Table Structure Table_Offer -------- ID FK Name start time end time MandatoryGroup -------- ProductId (FK to product) MixGroup1 -------- ProductId (FK to product) MixGroup2 -------- ProductId (FK to product) Table_offerDetails --------------...



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