An IniFile is basically the '''physical''' storage format for extremely simple table(s) or relvars, or possibly just a table row.

''It would be much more accurate to say that an IniFile '''can be''' the storage format for tables or relvars, but that's hardly insightful. Almost any record-oriented file format you care to invent can conceivably be the physical storage format for tables or RelVar''''''s.''

However in object oriented languages we use classes/objects to access, save, and load INI files.

I'd like to see programming languages where instead of using classes/objects/procedures to access the INI file, I could simply access the INI file relationally.

Imagine you could INSERT and UPDATE an ini file without having to use object oriented programming.  I suppose INSERT and UPDATE in relational languages can be considered somewhat procedural since you are doing some action "insert" or "update" or "select from" which is like a procedure.

Distinctions to be made: ini files are just the physical storage format. The model for accessing the ini file can be OO or relational.. or procedural, or a combination. 

'''Preferably INI files could be accessed relationally, the safest most logical way I can see.'''

One thing INI files have in them sometimes is descriptive comments and human notes, which makes INI files different than a CsvFile.
----
Sample code of what we should be able to do:

  iniDemo := openIniFile('test.ini');
  INSERT INTO iniDemo (windowHeight, title, windowWidth) 
               VALUES (200, "program 1", 643)
  closeIniFile(iniDemo);
----
Why IniFile is maybe not perfectly mapped to relational:
* Ini files have comments in them, it's a mixture of physical storage and a model, similar to the problem of XML
* Ini files are basically not normalized, they are more like a spreadsheet, a wide table
* Ini files don't always have repeat rows of similar data over and over, maybe some INI files are more like a single row (or cee struct) rather than a table
* Ini files are more like a long list of variables with values (or constants with values) along with human comments interspersed 

----
The Java view of INI-files (where they are called properties-files) is that of a Map. 
The Java implementation for loading and storing them (in the latter case comments are lost) is java.lang.Properties which implements the Map interface.
Now a Map is conceptually like a row, not a complete table, as mentioned above.
A Map can easily be mapped to an Object (e.g. by the Java beans convention). So I'd say INI-Files are best mapped to objects.

I once wrote a tool for a project where INI-files where parsed and corresponding source code was generated which represented the content of the properties file as an object.
This had the huge advantage that you could use name completion of your IDE to access these INI constants.

Example:

app.properties (the INI file):
  path.main = C:\testing
  path.log = C:\testing\log
  log_level = WARN

main.java (example usage source code):
  // usual
  Map props=new Properties("app.properties").load();
  new File(props.get("path.main"));
  // with generated class:
  new File(AppConstants.path.main)

AppConstants.java (generated source):
  class AppConstants {
    static class Path {
       static String 
       static String main = "C:\testing";
       static String log = "C:\log";
    }
    static Path path = new Path();
    static String log_level = "WARN";
  }

The obvious disadvantages are:
* You need some mechanism to keep the generated classes up-to-date, but usually this is easy with a modern IDE.
* You cannot dynamically modify the file. 
** Writing the given values can be easily added (just parse the file in a static initializer).

-- GunnarZarncke

----
See also AreOoAndRelationalOrthogonalDiscussion, XmlSucks