You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This will be a future change that will have a significant impact across all USGO applications. However, updating our databases to meet Normal Forms will make future projects far easier, as well as having a beneficial impact on performance.
For example, there are two player columns in the game table, instead there should be a player_game table that sits between player and game. Joining players to games more than once is bad style, and will lead to worse performance.
The first step will be planning the structure of the new database. Second, we will need scripts that will copy data from the old, to the new database. Step three will be updating existing USGO applications to match the new structure.
I advise the creation of views that mimic existing table structure as a way to bridge the gap, allowing for modest changes to existing applications.
Best would be to have stored procedures written that will better use the performance features of relational databases, which can then pass the data back to the front end via API's or direct calls through a DB connection.
This is a project I intend to champion, although it is not a priority at this time.
The text was updated successfully, but these errors were encountered:
This will be a future change that will have a significant impact across all USGO applications. However, updating our databases to meet Normal Forms will make future projects far easier, as well as having a beneficial impact on performance.
For example, there are two player columns in the game table, instead there should be a player_game table that sits between player and game. Joining players to games more than once is bad style, and will lead to worse performance.
The first step will be planning the structure of the new database. Second, we will need scripts that will copy data from the old, to the new database. Step three will be updating existing USGO applications to match the new structure.
I advise the creation of views that mimic existing table structure as a way to bridge the gap, allowing for modest changes to existing applications.
Best would be to have stored procedures written that will better use the performance features of relational databases, which can then pass the data back to the front end via API's or direct calls through a DB connection.
This is a project I intend to champion, although it is not a priority at this time.
The text was updated successfully, but these errors were encountered: