I’m available for full-time employment, remote development work, contract project work and so forth.

As you can see, this seems to the currrent design I am going with.

Shared Schema design with extensible tables.

Extensibility is via two tables which are either added for each table that we extensiate or they will all share the same extension tables. (undecided as yet)

• Property table

Table full of various attributes such as BigIntVal, IntVal, which allows you to store the data in it’s native type (hence avoid casting in the

application logic)

• Setting table

Which stores the name of the attribute (such as Username, Date of birth, etc) and the data type stored as a varchar, which allows

the application to lookup the correct attribute in the property table.

I’m undecided if this is a wise design choice; does the extra null values stored in the properties table overshadow any performance downturn by otherwise having to cast a varchar into it’s respective native type (think along the things of complex aggregate queries, were you would be summing total values)

The aspnet_users table is included here, because it’s used for user control with each tenant… We cannot add any additional fields (foreign keys namely) in the users table, so the foreign key linkage from tenant is therefore sent to the users_property table, instead. Again, I’m just working with what I’ve been told… It’s certainly not an elegant design solution.

This was my initial design for the database, but according to one of my colleagues this design isn’t ideal as far as performance requirements go…

I implemented a data type lookup table, but this approach would require the application to cast the varchar “values” into the respective data type.

Instead, this approach seems more suited. My objection to it was that it includes a lot of null values.

Database Science

Military Photos law