18.08.2014, 09:06
(Dieser Beitrag wurde zuletzt bearbeitet: 18.08.2014, 09:11 von silvermane.)
Putting everything into a single database seems like a good idea, but:
- the Steckbrief will be a complete mess until you apply some filters
- when adding squads, there will be problems with all those supercups and other competitions where a limited selection of players appear getting in the way of regular seasons
- depending on the number of competitions you want to include, you might have to add an enormous amount of teams. DFS is not well suited to handle this, as even on a fast computer you will have to wait several seconds when adding a new team if you already have a few thousand on them. If you then need to add another hundred this can be VERY boring. Thousands of logos will also cause a delay on startup, even if cached on a fast disk.
- thousands of entries make it very hard to select teams for competitions, especially international ones where you can't filter by country, as the in-built mechanism only recognizes the first key pressed
- your database will, in the long run, become unstable, unless you are a developer with the access to internals
- the most discouraging fact is that you must do everything yourself and by hand. You cannot import any data, nor can anyone help you run the DB unless they take over temporarily, during which time you can only twiddle your thumbs. And no matter what enthusiasm you start with, you WILL become discouraged sooner or later. Having to add stuff to a database at regular intervals is boring, even if you have learned to do it rapidly.
Also, consider that DFS is very inefficient when it comes to data storage. For example, storing 150,000 matches requires almost 30 MB (with just 100+ teams, so other tables are negligible). That's about 200 bytes per record, and line-ups etc. require even more space per unit of information.
Granted, most projects will not come close to such extremes, but this is something to keep in mind.
All of this could be avoided if DFS was able to pull out information from multiple databases simultaneously, but this is not going to happen (and would be difficult to implement anyway).
- the Steckbrief will be a complete mess until you apply some filters
- when adding squads, there will be problems with all those supercups and other competitions where a limited selection of players appear getting in the way of regular seasons
- depending on the number of competitions you want to include, you might have to add an enormous amount of teams. DFS is not well suited to handle this, as even on a fast computer you will have to wait several seconds when adding a new team if you already have a few thousand on them. If you then need to add another hundred this can be VERY boring. Thousands of logos will also cause a delay on startup, even if cached on a fast disk.
- thousands of entries make it very hard to select teams for competitions, especially international ones where you can't filter by country, as the in-built mechanism only recognizes the first key pressed
- your database will, in the long run, become unstable, unless you are a developer with the access to internals
- the most discouraging fact is that you must do everything yourself and by hand. You cannot import any data, nor can anyone help you run the DB unless they take over temporarily, during which time you can only twiddle your thumbs. And no matter what enthusiasm you start with, you WILL become discouraged sooner or later. Having to add stuff to a database at regular intervals is boring, even if you have learned to do it rapidly.
Also, consider that DFS is very inefficient when it comes to data storage. For example, storing 150,000 matches requires almost 30 MB (with just 100+ teams, so other tables are negligible). That's about 200 bytes per record, and line-ups etc. require even more space per unit of information.
Granted, most projects will not come close to such extremes, but this is something to keep in mind.
All of this could be avoided if DFS was able to pull out information from multiple databases simultaneously, but this is not going to happen (and would be difficult to implement anyway).