Build Your Own Arcade Controls Forum
Main => Software Forum => Topic started by: Howard_Casto on March 18, 2011, 03:37:18 pm
-
The past couple of weeks I've been trying to boost my programming prowess and catch up on languages I haven't used in ages.
I was wondering if Front-end powered by a programatically-created jet (or access to the non-programmer) database has ever been attempted. I remember playing with access YEARS ago when it was still slow and cumbersome and decided to go with a manually created array db for my fes and never looked back.
I was playing around with ADODB and SQL queries the past few days and have found the situation to be much improved. Filtering and sorting is now much faster and pulling the data from non-access databases is a tad easier. Also back in the day DAT files and mame's listinfo printout were all in proprietary formats, meaning a nasty and lengthy conversion to useable data. Now practically everything is xml-based so it should be possible to load files into a database via a simple conversion script.
I wrote a little app that converts DK's old text-based masterlist into a db and lets you perform various SQL search queries on it. Everything seems to be lightning fast.
I'm wondering if anyone else has attempted this though. I'm thinking all ADODB and no storage of data in controls or arrays. I'm just wondering aside from dll errors if there is any down-side.
-
I don't see why not - I've been playing around with something similar myself - using a SQL Server CE database, and WPF/.NET and linq to create a frontend. Unfortunately, life has got in the way! (It works, but I need to iron a few things out)
Not sure what major differences there are between an access database, and a SQL server CE database file.
The ultimate scenario I think would be having the one database, say sqllite (which is cross platform/ programming environment), that all the FE's could standardize on, including menu structure, etc. Then, you could use one universal application to 'maintain' the database, and use any frontend you prefer.....
-
What you really need more is a unified database schema,not a standard database. As long as your schema is the same, most modern languages should be able to connect to sqlite, SQL CE, mysql, hell even Access, as long as the data access piece of the application was written using a minimal amount of abstraction..
-
What you really need more is a unified database schema,not a standard database. As long as your schema is the same, most modern languages should be able to connect to sqlite, SQL CE, mysql, hell even Access, as long as the data access piece of the application was written using a minimal amount of abstraction..
Yeah, this is a major issue with emulators today. We are finally getting to a point to where info is standardized, but it's based on mame's listxml format and that format is terrible for loading individual games. Why? Well to be frank, xml is slow when you are dealing with such a huge amount of data. I think the listxml output is somthing around 50 megs now. 50 MEGS! It's a step up from listinfo because at least xml is parsable, but for fast lookup, xml nodes are really supposed to have a id number and a corresponding text list of the names and mame's listxml lacks such support.
Really mame, and all other dats, should be based on a delimeted text file. Sure they are ugly, but such a format can be instantly loaded into almost any database type and because of the lack of formating characters, the file is considerably smaller (all those brackets, slashes and carriage returns add up!)
I certainly understand why they don't do it that way... to the lamen the output would be virtually unreadable. It would still be a better, more flexible format though.
-
I certainly understand why they don't do it that way... to the lamen the output would be virtually unreadable. It would still be a better, more flexible format though.
How often are lay folk looking at it, let alone modifying it?
-
Well mame is a documentation project afterall... it wouldn't make a lot of sense to make part of the documentation unreadable.
-
I put together a data schema based on the XML in SQL Server some time ago, mostly just playing around with the XML to familiarize myself with it. The intent was to use it with SQL Compact edition, which is pretty easy to distribute.
I dunno, though. For something like mame, the state of the art with XML readers these day is pretty dang fast. Tie it with XPath, or better yet Linq2XML, and you can query that XML pretty dang fast. Bit of a memory hog, but you'd have to have .net loaded anyway..
Hmmm just noticed Mathew's comments, he and I are thinking along the same lines. I've been working on adding WPF support to my Engine18 plugin for mala. There's a serious amount of cool stuff you could do with a purely WPF FE.