4

The law of the instrument tells us that: If you have a hammer in your hand, every problem starts to look like a nail. So before jumping too quickly to a solution look objectively at the needs and requirements. In particular security needs, access control, and transactional consistency requirements. Blob in DB: Pros: benefits from the access ...


3

I have the same argument, with different conclusions. The problem statement is that you have large text objects that need to be stored, but did not mention what actions need to be taken outside of storage. Bottom line: Blob storage is cheap, fast, and just about seven nines of uptime Generally well secured, and you have good control over traffic can be ...


3

Your structure so far looks reasonable with a few caveats, so don't be too hard on yourself. I wouldn't store any information about the components in the Products table directly if possible, so get rid of the part_list_id col. The product_id will give you the hook to build the component list later. This also means that you could add 'temporary' products to ...


2

Normally, for full historical tracking, you don't need the current status in a different table. Instead, add two timestamps to your table which represent the start of the given time slice, and the end of the given timeslice. For an update, just set the end timestamp and insert a new row. Something like this: userid | status | validFrom | ...


2

You should store the replies as its own document because you can get scaling problems if storing with the review. This is an important part of DDD where it is called a consistency boundary. I assume you want multiple users to be able to post a reply independently of each other. If you are storing them together you can risk some replies fail just because ...


2

Ultimately, it depends on your requirements, specificially how often and for what reasons do you expect the application to lose the ability to reconnect? is it reasonable to assume a reconnect will be possible some minutes later? how much data can get lost in case there is unsaved data, and how important could that data be? Depending on the answers to ...


2

What the user assumes the inputs - trial options - are […] Don't allow the user to make such assumptions. With more that a handful of options, the user will guaranteed get some of them wrong. Instead, let the user give each combination of options they want to use a descriptive name before starting a simulation. Then the user can recall that set of options ...


1

When it comes to business logic we agree that DRY principle is a cornerstone of structuring it well. However, this is not always true for the database world. The main reason is that assembling needed information from different sources requires additional costs. If we talk about the same database-scenario this is what denormalization is for: sometimes you ...


1

Think of Elasticsearch as an eventually inconsistent index on top of your DBMS. The index is built once for a specific state of the database, but when the content of the DB changes, one will have to update this index afterwards (for example, in regular intervals, or somehow coupled to these changes). Depending on how one implements the update strategy, there ...


1

You are looking at a schema compare tool. If you do a schema compare into an empty database, the diff should contain your database structure. Then, quickly commit the source files needed to create a new empty database to source control before any more partying happens directly on the live database without an option to roll back or version changes.


1

I think both Cristophe and Berin make good points about the considerations. I will not repeat these but offer some basic advice based on some personal experience with this. If your database can support the LOBs you wish to store (they are within the limits for your platform) and your total space allocated to these LOBs is not a significant percentage of ...


1

In a nondistributed database system, nondistributed transactions are to satisfy ACID. Yes. In a distributed data store, what are distributed transactions to satisfy? ACID - but over a distributed system. Example You have a data message in a queue-system e.g. AMQP that you want to insert into multiple database tables. So there is two systems; queue-...


1

In the case of an SQL engine such as MySQL, the best option is to let the DB engine and its optimizer do the job: send the complex query and get the results. There are several reasons for that: SQL engines have in general an optimizer that is able to chose the best access strategy, taking into account dynamically the size of the tables, the existence ...


1

I can't reliably talk about all filesystems and all platforms. But I have some experience in dealing with file allocation reflecting disk/volume/partition/region structure. The most obvious way is present in WinNT NTFS disks. (I'm not entirely sure about other win FSes). It can be easily done using userspace defragmentation API. From my point you can not ...


1

Even if I'm late, I would to put my 2 cents on the argument because I think it's an important point when you want to evaluate e design an event-driven microservices architecture. Each microservice knows exactly which are the events that impact on its state and is able to wait for them. When the microservice is not avaliable, there should be a component that ...


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