CSV in a database



  • A dev on my team is storing CSV in a DB to save the options of the (pure client side) application.  Now the DB _is_ being used for good on the client site (it is a light weight integrated DB), but storing options in it seems too much like a "look, I have a hammer!!! POUND POUND POUND" sort of a solution.

    Especially since the code to insert and retrieve the options is so... ick.

    I am thinking of telling him just to use Java's built in Preferences class.  Does this reimplementation of the wheel deserve such judgement?           

     



  • I think it's more like "I don't need a hammer.  Look, I have a shoe!!!  POUND POUND POUND."

    You'd better hope he doesn't find the Preferences class on his own.  That one allows you to get to the system registry.  "Look, I have a nail gun!!!   BANG BANG BANG oops ouch."

     



  • @newfweiler said:

    I think it's more like "I don't need a hammer.  Look, I have a shoe!!!  POUND POUND POUND."

    Forehead, dude. You hammer in nails with your forehead.
     



  • Let's face it: if he finds the Preferences class, he'll just make the same CSV string and store it using a single prefs.put("options", csvString).



  • Oh, various prefs are stored in different csv strings.

     

    :-p      

     



  • The best part of it all would be if the db stored the connection string for the client to use to connect to the db



  • @com2kid said:

    A dev on my team is storing CSV in a DB to save the options of the (pure client side) application.  Now the DB is being used for good on the client site (it is a light weight integrated DB), but storing options in it seems too much like a "look, I have a hammer!!! POUND POUND POUND" sort of a solution.

    Especially since the code to insert and retrieve the options is so... ick.

    I am thinking of telling him just to use Java's built in Preferences class.  Does this reimplementation of the wheel deserve such judgement?           
     

     
    Why is he not just using a Preferences table?   Why a CSV?  this makes no sense at all. either store it in a file, or store it in a database, don't store it in a database in a file format !!

    This is yet another case where a horrible design decision, made because it's "quicker and easier", results in much, much more work and longer, buggy, complicated sql statements just to do simple INSERTS and SELECTs and the end result also ends up being a big mess.

    Pick one or the other: database or file.  And store it in an appropriate manner for whichever method you choose.



  • We've got a lovely one where we store an XML file that represents simple config settings in a column in a row in a table. There is basically only one row in this table for a given project, too. A table with a single row, with basically one column, that holds an XML file that basically represents a table of settings.



  • Are your settings hierarchical in nature?



  • Hell no.


Log in to reply