in reply to Re: key value in text format
in thread key value in text format

I'm not sure I should create a new post. Let's say I'm using SQLite, but SQLite supposedly cannot be reliably locked on NFS so multiple processes could not safely manipulate database w/o corruption. Since the application may be running multiple instances to crunch data files and inserting to a database file.

If I create individual database file for each raw file, then I've to merge them; and need to manage parent/foreign key constraint.. The final database file should reside on NFS, so other applications can access (read).

Replies are listed 'Best First'.
Re^3: key value in text format
by GrandFather (Saint) on Nov 07, 2019 at 02:27 UTC

    That just raises the DB requirements and puts any text file based solution right out of the running. The solution is essentially the same, but use one of the other DBD:: modules to access your database of choice. Once you get beyond simple requirements that can easily be met by SQLite you will find fairly strong division between proponents of different databases.

    The saving grace is that you can do a lot of development against DBD::SQLite then migrate to using the more serious database of your choice when the system needs to hit the NFS.

    Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
[reply]

      Guess I'll use DBD::SQLite during development and switch to DBD::mysql for production use.

[reply]
        Please, use DBD::MariaDB instead of DBD::mysql to prevent hair loss.

        map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
[reply]
[d/l]

In Section Seekers of Perl Wisdom