SQL database of iNES mapper numbers

What I think can be useful is SQL database of iNES mapper numbers, possibly using SQLite. I know how to operate SQLite, and can make such thing, you can make some suggestion/comment/idea/complaint in here, so that we can work to make it together.

Some of possible data might include: discrete/ASIC, rarity, extra audio channels, bank size, max PRG ROM, max PRG RAM, max CHR ROM, max CHR RAM, scanline IRQ, support of PowerPak, support of emulators, Verilog codes to implement it (if available), company that makes it, other features of mapper, and probably many other things I forgot about.

It might help if you can put the INSERT statements into the wiki articles of each iNES mapper number, and to make up another file which contains the CREATE TABLE statement, and then write a program that will download it and put it into one file on your computer.

An RDBMS is overkill for this. There are many, many simpler formats that one could use to define this information, and with way, way less overhead.

Phrased differently: why do you need SQL for this? What does SQL get you for this which you cannot get with a multitude of other formats (comma-delimited, tab-delimited, ASN.1, XML, YAML, JSON...). What problem are you trying to solve that justifies use of SQLite for this?

Also: while SQLite is useful for a lot of things (especially environments where you need RDBMS-like functionality but in something standalone/simple), it lets you get away with some absolutely atrocious crap like permitting insertion/updating of numeric (INTEGER, etc.) fields with string values -- and this is by design {1}{2} (read 2nd paragraph at both URLs) with no way to inhibit it.

SQL is useful for this since you can perform SQL queries on the data, in order to figure out which mapper you need, and possibly to easily convert the data using SQL queries, too. It also means that using INSERT INTO with a field list, you can add new fields later on even before you update the other records with the values for those fields.

You can use other formats if you like to and convert to/from SQL, too, of course, if that is what you prefer.

(I have read the stuff about SQLite; yes I know how it works, and I have written entire programs in SQL using SQLite too; I know about how all of it works.)

Politely: you really haven't answered my question. :-)

Why do you need an RDBMS with a single table containing a list of mapper numbers and their capabilities/details? What does an RDBMS give you in this situation that a flat file (or those I mentioned) doesn't?

Telling me "you can query the data" is not really an answer -- you can "query the data" with the other formats I mentioned as well, and with a hell of a lot less overhead. Open file, parse it, store it in memory in a linked-list struct.

If you're advocating use of an RDBMS to store mapper details for something like the equivalent of BootGod's NesCartDB -- i.e. a web service -- where you're doing searches for certain parameters of mappers, then sure, that makes sense. But if this is for, say, an emulator or "informational project" (dump a list of all mappers and their capabilities), using an RDBMS gets you nothing.

So, context please? :-)

Also -- and this is probably me not understanding what you mean -- you can't use INSERT INTO with a field list of a non-existent field in a table. You have to alter the table schema first via ALTER TABLE. With text files, this is the equivalent of changing the descriptive header (representing all the fields) and adding the new data (one entry per mapper); depending on the format you're welcome to leave the field empty (e.g. field: "" or the equivalent). My point is that it's the exact same method/"procedure" you would have to do with an RDBMS.

Well, yes; like I said, it could be in any format since you can convert to whatever you need. For example, convert JSON to XML, or to make a virtual table module to load XML data into SQL. The data could also be stored in a MediaWiki template format (probably best, since that way it can be stored and used in the wiki and also easily converted into whatever format you need for download).

No, not a web service; I don't really like web service much. Yes, it is just an informational project.

Correct that it is probably you not understanding what I mean in this case; you cannot INSERT INTO with a field list of a non-existent field in a table. I meant that you can use ALTER TABLE to add those fields (or simply alter the CREATE TABLE statement if it is stored in source code form), and then then the data can be added later. I am sorry, I was being unclear; I did mean the other way around from what you thought I meant (which is what it does actually seem to mean). Nevertheless, like I said above, I suppose MediaWiki template format is best since it can already do this (you can add as many fields as you want and it won't do anything with them unless you tell it to do with one of them specifically).

Thanks for the clarification -- I stand firm on that an RDBMS is overkill for what it is you want to do. I've also linked this thread to a couple colleagues (who do professional programming / database management) and they agree, it's overkill. Their initial response was "Is this for some kind of search engine or something like that Cart database?", to which the answer is no, and their reaction was "well then there's really no gain to using an RDBMS compared to any of the other formats you listed". The only driving force I can see is "hehehehehehehehe I like to play with SQL hehehehehehehehe". :-)

You're absolutely welcome to do it if you want/need to, of course, but there just isn't any benefit to it. It seems like a whole ton of physical time/labour followed by CPU cycles wasted for no real gain. :-/ But if it's a project you're passionate about, honest -- don't let me rain on your parade, you should do it if you feel strongly about it.

Yes I understand what you are saying; I suggested using MediaWiki template format rather than SQL. (It can then be converted to whatever format you need, including but not limited to SQL.)

I too agree that an RDBMS is overkill, but I also happen to think that SQL is not a bad programming language for doing these kind of queries and so on, and to combine it with other things if someone is doing so.

MediaWiki templates is probably the best format to store the data in (something like how the list of Z-machine interpreters on IFWiki is written), though, so that it can be used in the wiki, editing by everyone like it is in the wiki, and can be downloaded to convert into whatever format you need.