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. ...
I suggested relational database because there are lot entities with relations between them.
So logically-related Entities call for a Relational database.
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 ...
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 ...
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 ...
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 ...
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.
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 ...