New answers tagged database-design
0
A general idea to cut your issues down with the aim of Microservices paradigm would be a strategic pattern of DDD which called context mapping. In the context mapping you define the type of the relations between your bounded context and you shape your domain models which may seem are duplicated in names, though these are different in usage.
For the example ...
1
I can see you boss's point of view. A PERSON can exist without an ASSIGNED_LEVEL and so, from a purist perspective, ASSIGNED_LEVEL doesn't belong "in" the PERSON Entity.
However, the physical implementation of an Entity (i.e. a Table) need not be exactly the same structure as the Entity. For performance or other reasons, you may choose to model the data ...
0
Now I think this would be a huge performance issue....
Stop. Do not waste time solving performance problems that you do not have. The link Ewan posted indicates that MySQL allows for JSON-querying. Use that for as long as you can. All the big relational databases now offer JSON support to a surprising degree, because they all understood that they were about ...
2
I suggested relational database because there are lot entities with relations between them.
So logically-related Entities call for a Relational database.
Good thinking.
He then told me to just store everything in form of JSON so we can easily add new attributes.
And that's where things went wrong.
Storing big blobs of "stuff" in a database is ...
1
With a lot of things defined vaguely, I'll still hazard to suggest a few things.
Where there is a hierarchy (a tree), there are paths. Look at the file system.
If I the number of path steps is fixed, I would just have a tuple of (cabinet_id, shelf_id, box_id, row, col) for each item, and index them in that order. This would allow for efficient range ...
2
There are a number of unknowns in your description, so either of the two solutions (or a somewhat different one) could be best suited.
If the containers are managed in a hierarchy (an item is at a location in a box, the box is on some level on a shelf etc.) designing data structures around these containment relationships might make sense. If all you have is ...
2
Probably. It is hard to tell from your story though. If the fields are only there to keep track of a sequence of events and an integer field is smaller than a date/time field and disk usage was of any concern at the time of design, it may have been a good decision.
Like you say no one ever really seems to care when and it is all about before and after. ...
1
Any algorithm that requires you to compare each set to every other set is doomed to failure. It's an O(n2) problem.
The classic way around this is either minhash + LSH, or, if you only wish to detect near-identical sets of titles, simhash.
Both approaches reduce it down to an O(n.log(n)) problem. Both are statistically based: they are not guaranteed to ...
0
It would be better to use composite primary key as it will be combined together so that the combination is unique. It will allow you to set multiple unique columns as a constraint.
1
You need three tables: an Events table, a Guests table, and a linking table having GuestID and EventID. Otherwise, a given guest will only ever be able to attend one event.
Don't spread an entity over multiple tables. Always prefer adding an additional column that distinguishes groups of entities, but make it a single table.
1
Its generally better to provide fine grained permissions, this makes it possible to change the exact set of information and actions available to a given user. But as you've noted this means being uber specific.
One solution is to order your permission names hierarchically, and use a matching technique like prefix matches, or full regexs.
ie:
Customer....
2
A role is set of functionality grouped as one like in your case SALESMAN what a salesman can do is driven by permissions, so permission define what functionality is allowed or not.
Basically now there is user which is performing SALESMAN role for which user gets certain functionalities based on permissions which it can perform. Now when a user with SALESMAN ...
0
Use standard queue based system rather than scanning database for rows to process it will be efficient and can act as event store as well.
Use Domain Events to decouple Bill, Trip related events from any other logic processing.
Not sure why you are clearing the database once marked processed, it these are temporary tables then these can be replaced with ...
0
(It's a cool project, of course there are products that you can buy that do it for you.)
General suggestions to look for:
Catching the events of interest (pipeline move for example).
Process them efficiently and reliably. Currently, you are handling it on your computer and writing it to a file (Is it reliable to your needs ? What will you do when ...
Top 50 recent answers are included
