postgres support in blitzmax
BlitzMax Forums/BlitzMax Programming/postgres support in blitzmax
| ||
| it is planned, to bring any database-support in blitzmax e.g. for postgresql-databases? postgresql is a ideal candidate, no cost and extremly advanced database. |
| ||
| What would you use it for? |
| ||
| Actually I would prefer Firebird myself. Last I heard, there where no plans to integrate databases, SQL or ODBC support in BlitzMAX. I'm pretty sure someone will write a module for it eventually. What would you use it for? Storing data? |
| ||
| PostgreSQL isn't a good choice for a game, IMO. Apart from being far too slow for real-time acces, it would require all your users to install it separately and configure it before your app could be run. A better choice would be SQLite or FastDB, which are both small, self-contained and have simple C APIs. FastDB in particular is good because it stores the DB in RAM rather than a slow disc file. |
| ||
| i wont use it for games, but e.g. for film and sitcom description-databases. i wrote a statistic-program for day of defeat in php (like psychostats) and will port it to blitzmax. a database in background for the parsed player-statistics(over years) is essential to do that. i cannot believe that blitzmax doesn´t have database-support because almost every other programming language has this e.g. other basic-languages: purebasic,hbasic,gambas. |
| ||
| Actually I have a mod started for Firebird I just dont have the time to finish it at the moment. Maybe someday |
| ||
| i wont use it for games, but e.g. for film and sitcom description-databases. i wrote a statistic-program for day of defeat in php (like psychostats) and will port it to blitzmax. a database in background for the parsed player-statistics(over years) is essential to do that. i cannot believe that blitzmax doesn´t have database-support because almost every other programming language has this e.g. other basic-languages: purebasic,hbasic,gambas. Well BlitzMax is a games programming language, not a general-purpose language so there's no reason to have a slow DB connection. A better method is to connect to the internet via a PHP script for these stats. You could also connect to the database directly using raw sockets if you must. |
| ||
| Last I heard, there where no plans to integrate databases, SQL or ODBC support in BlitzMAX. I heard vague rumours near the initial launch of the win/linux betas but nothing since then and I certainly wouldn't hold my breath. The 3D, GUI, sound/music and networking modules will take BRL long enough! |
| ||
| ... |
| ||
| there's no reason to have a slow DB connection. First of all, a database connection is faster then a file for random access or sequential access on a heavilly fragmented drive. Additionally relational databases give you more control over how you want to organize your data and objects compared to a flat file system. A better method is to connect to the internet via a PHP script for these stats. That would not be a better method by a long shot! Parsing php output is much, much slower than traversing a resultset - particularly if we're talking about large ammounts of information. |
| ||
| First of all, a database connection is faster then a file for random access or sequential access on a heavilly fragmented drive. Yes. But why would you want to use something as powerful as Postgres just as a storage method? For it to be worthwhile you'd need to be doing a lot of random accesses during the course of the game and a heavyweight database just isn't practical for that sort of thing. A database query that takes 0.01 seconds to complete is fine for business, but that's a whole frame of your game gone in just one query. If you need a lightweight databases for non-realtime file access and the occasional query then SQLite is pretty good because you can embed it into your program. For complex relational data tables with many queries (e.g. if your game uses a lot of stats) then a RAM-based DB like FastDB might be better than not using a database at all. YMMV. That would not be a better method by a long shot! Parsing php output is much, much slower than traversing a resultset - particularly if we're talking about large ammounts of information. Not faster, but a web service would be easier, more flexible, more scalable and wouldn't require the end user to install and administer the monster that is Postgres. And there's always the option I mentioned of connecting to a remote database directly. I love Postgres by the way, but it's really not suitable for games in the same way that Blitz isn't designed for non-games programming. |
| ||
| For game development. I'd say all you really need is a good XML file module. One that will read in an Xml file store it in memory, and allow you to navigate all of it's nodes. Hey! There's an idea for a quick learning project. I'm going to write an XmlDocument object in BMAX that's similar to the XmlDocument object in the .Net framework. -Jim |
| ||
| or... Someone could write a module for Python: http://www.python.org/doc/2.4.1/ext/embedding.html http://www.python.org which could be used for high level access to Databases, XML parsing, key-pair dictionaries, game scripting, etc good enough for Google, good enough for me: "Python has been an important part of Google since the beginning, and remains so as the system grows and evolves. Today dozens of Google engineers use Python, and we're looking for more people with skills in this language." said Peter Norvig, director of search quality at Google, Inc. not to mention Bittorrent was written in Python (wouldnt that be cool?) |
| ||
| Yes. But why would you want to use something as powerful as Postgres just as a storage method? Because you're working in an object oriented environment and a relational database is rather good for storing an object states and relations? A database query that takes 0.01 seconds to complete is fine for business, but that's a whole frame of your game gone in just one query. Which might not be a problem, depending on when you query. If you need a lightweight databases for non-realtime file access and the occasional query then SQLite is pretty good because you can embed it into your program. That depends on your datamodel. If your datamodel requires a centralized permanent storage, then an embedded DB, is probably not the best solution in the world. For complex relational data tables with many queries (e.g. if your game uses a lot of stats) then a RAM-based DB like FastDB might be better than not using a database at all. Again - only within the same domain. In a distributed system, it's entirely useless. Not faster, but a web service would be easier, more flexible, more scalable and wouldn't require the end user to install and administer the monster that is Postgres. Who said anything about the end-user having to install Postgres? I love Postgres by the way, but it's really not suitable for games in the same way that Blitz isn't designed for non-games programming. Surely that depends entirely on which kind of game you're planning to make? And there's always the option I mentioned of connecting to a remote database directly. Yes. But going through ODBC (or a similar standardised framework) is likely to be better, because you don't have to change any of your game logic to accomodate a change in technological platform (if you wanted to switch from Postgres to Firebird for instance, you would just have to switch the ODBC driver and be done with it). For game development. I'd say all you really need is a good XML file module. One that will read in an Xml file store it in memory, and allow you to navigate all of it's nodes. Yeah. Because most of your players are going to have Internet connections that allow for 32-way peer-peer connections for sending XML. It depends on what game you're making. Hey! There's an idea for a quick learning project. I'm going to write an XmlDocument object in BMAX that's similar to the XmlDocument object in the .Net framework. Good idea! Keep me posted on how that one develops. |
| ||
| Yeah, it does depend what you're doing. But if you're hoping to write a game with direct real-time remote access to a database designed for robustness over speed, or if you want to have 32-way networking using a peer-to-peer model, you're going to have problems whatever you do. :) If, however, you're looking to store gameplay scores and stats centrally, or poll a central database periodically, a web service (e.g. PHP script) with a database backend would be ideal. If you're looking to save data to disc and restore it from a local file in a complex manner, you really don't want to use postgres because it means the end user has to install it separately. |
| ||
| Python has an interface to Postgres. we just need a Python module (wink-wink) http://www.pygresql.org/ http://www.python.org/topics/database/ |
| ||
| If, however, you're looking to store gameplay scores and stats centrally, or poll a central database periodically, a web service (e.g. PHP script) with a database backend would be ideal. Well "ideal" is pushing it, but it's a good solution. The problem with such a webservice is that it's hard to safeguard against cheating (or rather cheating is easier [just send the correct http request, which you can get by packet sniffing and playing the game] for those who know how). Python has an interface to Postgres. we just need a Python module (wink-wink) Does it have one for FireBird aswell? A Python module would definately be a good thing tho'. |
| ||
| For game development. I'd say all you really need is a good XML file module. One that will read in an Xml file store it in memory, and allow you to navigate all of it's nodes. FlameDuck Yeah. Because most of your players are going to have Internet connections that allow for 32-way peer-peer connections for sending XML. It depends on what game you're making. I've started working on the TXmlDocument class. In the process I've created a THashtable class as well. You can see my worklogs here: THashtable http://www.blitzmax.com/logs/userlog.php?user=2855&log=479 TXmlNode http://www.blitzmax.com/logs/userlog.php?user=2855&log=480 The hardest part will be parsing an Xml Document and creating the Nodes/Attributes, and Child Nodes contained therein. -Jim |
| ||
| For me an interface that would allow for serially storing objects to disk, and restoring them would be great. |
| ||
| >First of all, a database connection is faster then a file for random access or sequential access on a heavilly fragmented drive. It depends on the mass of the data you are working with and how you save them (with/without own index, with/without BTree). Initial connecting to PostgreSQL and initiating the SQL-Request takes access-time, too. PostgreSQL rulez, Delphi is a better choice for database-appz. |
   |