Thread: Player xferring

Originally Posted by Kiissmyswagb

Players are not constantly being saved and updated. They are loaded on login and then saved on logout. The duration between this time could be ages.

I'm not using any "crap" databases. If you used Oracle SQL and want to migrate to MariaDB you can't just simply export your table and expect it to magically work. Even if you could, you can't easily move your database to another host entirely without exporting the entire thing and then importing it into the new systems. That's just how a database is. Next up security; databases are way more vulnerable especially if you have remote access. Performance; opening a connection to a database and running queries is far more expensive than just editing a json file. Your database is also locked until the connection is released.

An addition to your point; Adobe often store their program data in JSON formats. Adobe Animations entire project file can be saved as a JSON (I think it's Animation, may be wrong, or one of their products).

I do agree that SQL is a better approach for player saving but there's no way we can say that JSON is a bad idea or inferior.
Look at how XML is used in the real world.

You might not be saving and loading individual players but you are possibly saving and loading players at the same time.

I don't really understand your point about migrating from Oracle SQL to MariaDB. That's like saying my JSON doesn't work because it isn't XML. In the ordinary meaning of the word 'portability' as in platform-independence, SQL is as portable as the implementation, and there are portable options.

Yes databases can be unsecure, as can storing data via JSON. You still require remote access (the data needs to be sent either way).

I also don't see your point about 'opening a connection to a database and running queries is far more expensive than editing a json file'. This is not about editing the file (though I have never had any problems, with ORM you barely have to deal with the SQL directly anyway), and retrieval via SQL is by no means slow.

I also don't see why you say JSON is more secure and then point out that SQL has database locking. This is a security measure.

I'm sure Adobe use JSON for a lot, as do many professional companies. I use it myself, just not for player saving.

Originally Posted by Fire Cape

You might not be saving and loading individual players but you are possibly saving and loading players at the same time.

I don't really understand your point about migrating from Oracle SQL to MariaDB. That's like saying my JSON doesn't work because it isn't XML. In the ordinary meaning of the word 'portability' as in platform-independence, SQL is as portable as the implementation, and there are portable options.

Yes databases can be unsecure, as can storing data via JSON. You still require remote access (the data needs to be sent either way).

I also don't see your point about 'opening a connection to a database and running queries is far more expensive than editing a json file'. This is not about editing the file (though I have never had any problems, with ORM you barely have to deal with the SQL directly anyway), and retrieval via SQL is by no means slow.

I also don't see why you say JSON is more secure and then point out that SQL has database locking. This is a security measure.

I'm sure Adobe use JSON for a lot, as do many professional companies. I use it myself, just not for player saving.

The Oracle to Maria DB was a comparison to how JSON can easily be converted to XML (for example) and with minimal effort.

JSON is an offline file format so I don't understand the remote access. If you're calling it via a REST API, SSL could solve most your problems.

You still have to write your select query's with ORM.

Running a query is slower than opening a file.

But like I said, although SQL is a better approach, there's no need to deny JSON or the recommendations.

Originally Posted by Kiissmyswagb

The Oracle to Maria DB was a comparison to how JSON can easily be converted to XML (for example) and with minimal effort.

JSON is an offline file format so I don't understand the remote access. If you're calling it via a REST API, SSL could solve most your problems.

You still have to write your select query's with ORM.

Running a query is slower than opening a file.

But like I said, although SQL is a better approach, there's no need to deny JSON or the recommendations.

Yes but why do you need to convert from Oracle SQL to Maria DB? To me that is like saying Java is bad because it is hard to convert it to C#. Why are we even migrating in the first place?

There are still security implications of storing data in JSON format. This is client-server after all.

Indeed you do.

My big question to you is why you even need to edit player files manually? That sounds like bad design. That is the main reason I would use SQL over JSON. I use JSON for configuration that I am likely to change manually.

Originally Posted by Fire Cape

Yes but why do you need to convert from Oracle SQL to Maria DB? To me that is like saying Java is bad because it is hard to convert it to C#. Why are we even migrating in the first place?

I had to do that recently Oracle SQL was free to use (old old version) and when Oracle slapped the licensing stuff we didn't wanna pay. So we switch to an open source db, MariaDB.

It's not client server. The files won't be transferred and most likely always will be local.

You don't need to change the player files manually however if the OP has no SQL knowledge, it'll be a learning curve.

Originally Posted by Kiissmyswagb

I had to do that recently Oracle SQL was free to use (old old version) and when Oracle slapped the licensing stuff we didn't wanna pay. So we switch to an open source db, MariaDB.

It's not client server. The files won't be transferred and most likely always will be local.

You don't need to change the player files manually however if the OP has no SQL knowledge, it'll be a learning curve.

Fair enough but that could happen with anything. I remember the scares about Java when acquired by Oracle.

Likely is the operative word. We know in reality that servers here get compromised anyway, if your database can get compromised your server probably can to. The files may not need to be directly exchanged client-server but some of the data will, if you have shit security someone can retrieve this data (how many servers are using rsa / isaac properly in 2021?). In other words this is a limit of the person not choosing to be proactive when considering security and not any inherent disadvantage to SQL.

It will be a learning curve but that doesn't mean it isn't better.

Originally Posted by clem585

I'm not too informed about hibernate, but wouldn't it get kind of difficult to maintain for a big RSPS with alot of data to store? You would end up with like 50+ tables. Wouldn't it be easier to use an object-oriented DB for player saves?

It is object-oriented. It's ORM (object-relational mapping).

Originally Posted by clem585

I'm not too informed about hibernate, but wouldn't it get kind of difficult to maintain for a big RSPS with alot of data to store? You would end up with like 50+ tables. Wouldn't it be easier to use an object-oriented DB for player saves?

Why do you think you would end up with 50+ tables?