New answers tagged

1

The alternative to this design would probably what you already suggested: giving each web app instance a database or database instance of its own. So this is a trade-off between these two design approaches. Benefits of the multiple-database approach: better separation from the perspective of safety and security (if one app instance corrupts its database ...


1

Don't use option 2. It's always a recipe for disaster when people get the idea "hey, if I store things here as text, I can do all kinds of things and the database can't prevent me from shooting myself in the foot". So you're trying to store the whole state of the graph at a given time. In that case option 1 would work. While an asset doesn't have a direct ...


1

In the past, when I needed this capability, I employed a Generic Key strategy. It looks like this: Generic Key Type Table GenericKeyTypeID TableName FieldName 1 Table1 FlagID 2 Table2 FlagID 3 Table3 FlagID You can have as many combinations of table and field in your Generic Key ...


5

Trying to create a single field that holds two types of data is not something I would recommend. It would make it impossible to have a foreign key to the members table. I think the two column approach is the best way to go. I would consider using a view here that unions the join against the members table and the ad hoc names. That will remove the ...


8

I always favour making this kind of thing explicit. Rather than using user_id == null to mean "deleted", just having a deleted boolean and set that to true when appropriate. Just make sure your repository layer or similar knows about the flag and returns deleted topics only in the circumstances you actually want them. In most cases, it wouldn't have two ...


Top 50 recent answers are included