sql questions

A while ago, longer than I like to admit, I made my living coding in Clipper, an xBase or dBase language. It had it’s own database manager which meant the developer had to control the structure of the data files, separate index files, and file/record locking in a multi-user environment. It’s now 18 years later, with nothing more complicated than installing openSUSE, and I’ve gotten the urge to write something. Just for myself. Don’t know what yet, just for, I guess, old times sake, to see if I can still do it. This means C source and I’m guessing maria or another sql file manager, although I notice a dBase library is available.

My question is: How much does maria handle by itself and how much does it do by itself? I know I can create the files, and the links between them, and specify the sort orders that will usually be needed thereby creating indexii, but will I need to control the locks? Does each query result in a physical file being created? What is recommended as a tool for formatting and printing a report?

Or, am I way overdoing things?

Bart (Hoping this turns into a long, drawn out, opinion driven thread.)

On Fri, 30 May 2014 04:06:01 +0000, montana suse user wrote:

> A while ago, longer than I like to admit, I made my living coding in
> Clipper, an xBase or dBase language. It had it’s own database manager
> which meant the developer had to control the structure of the data
> files, separate index files, and file/record locking in a multi-user
> environment. It’s now 18 years later, with nothing more complicated
> than installing openSUSE, and I’ve gotten the urge to write something.
> Just for myself. Don’t know what yet, just for, I guess, old times
> sake, to see if I can still do it. This means C source and I’m guessing
> maria or another sql file manager, although I notice a dBase library is
> available.
>
> My question is: How much does maria handle by itself and how much does
> it do by itself? I know I can create the files, and the links between
> them, and specify the sort orders that will usually be needed thereby
> creating indexii, but will I need to control the locks? Does each query
> result in a physical file being created? What is recommended as a tool
> for formatting and printing a report?
>
> Or, am I way overdoing things?

Choice of database really depends on the goal of what you want to
accomplish. You can code SQL queries directly in code using the mariadb/
mysql libraries (in whatever language you want), but you might find
something like sqlite3 to be easier to work with.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

If you’re building something very small,
You probably wouldn’t want to install a “big” RDBMS like MySQL/Maria,

You’d probably want to use a file-based database without the overhead… probably something like SQLite. Typically, you don’t need to install a full-blown RDBMS to implement SQLite, you only need to instruct the app how to inspect the file’s contents.

I assume the Clipper you wrote was an early version of an IDE, I’d recommend the same for your new projects. A good IDE will allow you to specify a SQLite and automatically setup your database connections. Although I never wrote using Clipper, I’ve observed many who either did or referenced, it was/is a good tool. Maybe you can still write using that tool even today?

TSU

I think you should learn a little bit of SQL first. It is a far more abstract language than the methods of handling dBase-files in Clipper (yes, I had to work with Clipper too in the last century). In SQL you don’t need to care for the physical details of files, indexes, locks etc., you just specify the “logical” query.

Depending on the programming language of your choice, a typical query work flow may look like this:

  • create a connection to a database server or open a local database file in case of sqlite (the sqlite-“file” contains the whole database, not just one table)
  • issue a query : “select column1, column2, column3 from table5 where column4 = 1234 order by column1, column3”
  • get a “result set” in return (usually a memory structure)
  • iterate over the single rows of the result set and do something with the data
  • close everything

The database system will care for locking, using appropriate indexes (if such indexes exists) and where to write/read the data physically to/from.
But there are other things to care for, e.g. transactions.

Hendrik