• (cs) in reply to Sean

    Sean:
    The real WTF is that this is how Visual Sourcesafe worked up until the VS 2005 release.

    Actually, Visual Source Safe 2005 still uses the file/directory based structure. It is the Team Foundation Server Source Code Provider that uses SQL Server to store the data.

  • Mikey (unregistered) in reply to iwan

    "student #3040557 was allowed to unlock the door with his card. As you might also guess, her debit account balance was stored in /accounts/balances/"

    So not only is the system a debacle, but the students have gender issues. Great.

  • (cs) in reply to DrPizza
    DrPizza:
    There are bigger problems than transactions.  Filesystems don't have any good semantics for non-hierarchical structures.  You could have a "directory" for "tables", "views", "stored procedures", "user-defined functions" and so on and so forth, and then just dump everything into each of those, but by failing to expose relationships between the data you'd lose all of the good stuff about relational databases.  Sure, you could just have a bunch of flat tables without any internal linking, but it doesn't seem very useful.  There's just no good filesystem analogue to a foreign key, for example.

    Yay! A response to my posts worth reading!

    Yes, you're right, and that is a deficiency. One way of looking at that deficiency is to say that's a deficiency of 'find' and not inherently a deficiency of the filesystem itself. If you could come up with some rational way of applying a 'select' query to a filesystem where you have a directory for a table and so on, then you could still work with those kinds of relationships.

    But, that still leaves the problem of creating directories and telling the DB that various parts of them are related somehow so you can have the DB maintain relational integrity for you if you want. Implementing that starts getting really ugly.

    But, I would consider the ability to be able to manipulate at least full tables by moving them around with standard filesystem commands, and to be able to see at least the contents of each row to be a great improvement over the current situation. And doing so would be a way to write programs that stuffed their data in the filesystem, and could more easily be migrated to a relational database later if it was needed.

  • scarhill (unregistered)

    I once wrote a system like the one described, using the file system to lookup the data needed, rather than using a database.

    In my defense

    • I was a freshman in college
    • It was in 1975


  • (cs) in reply to Omnifarious
    Omnifarious:

    Yes, you're right, and that is a deficiency. One way of looking at that deficiency is to say that's a deficiency of 'find' and not inherently a deficiency of the filesystem itself. If you could come up with some rational way of applying a 'select' query to a filesystem where you have a directory for a table and so on, then you could still work with those kinds of relationships.

    But, that still leaves the problem of creating directories and telling the DB that various parts of them are related somehow so you can have the DB maintain relational integrity for you if you want. Implementing that starts getting really ugly.

    But, I would consider the ability to be able to manipulate at least full tables by moving them around with standard filesystem commands, and to be able to see at least the contents of each row to be a great improvement over the current situation. And doing so would be a way to write programs that stuffed their data in the filesystem, and could more easily be migrated to a relational database later if it was needed.


    The AS/400 aka iSeries from IBM has a file system that behaves like a database.

  • (cs) in reply to scarhill
    Anonymous:
    I once wrote a system like the one described, using the file system to lookup the data needed, rather than using a database.

    In my defense
    • I was a freshman in college
    • It was in 1975


    I once wrote a system that used a single file in the file system instead of a database (like the previous system that was replaced with my system).

    In my defense, there were at most 4 kilobytes of data to save; in fact, the file was only necessary to recover after crash. The customer was surprised that the new system did not need a time-consuming database recovery after a power outage.
  • (cs) in reply to mrsticks1982

    The first ones got it right.

  • guest (unregistered)

    I was an oracle dba and a unix admin during the first decade of my career, and I've been a developer for the second. (I was a developer prior to graduating college, and I really enjoyed the creative outlet, and I eventually got super tired of admin work.) I'm continually dumbfounded by developers I come across who, for whatever reason, are just dead set against using a database for things that would clearly benefit from doing so.

    One guy in a manufacturing environment insisted on writing his program in C, in Unix, and making it run from the command line, on a critical production server. He sneered at the whole notion of a database, saying that software that uses a database is "data centric". Instead of using a database, his program used a bubble sort, to sort an entire large data file, in memory. It took up 2/3rds of the server's memory doing it. So his non-"data centric" program used a bubble sort to sort a big batch of..?

    The production manufacturing system that server ran slowed to a crawl while his program was running. And running, and running.. it was like a farting energizer bunny. Just when you think it's gone, you find it has lingered on.

    I asked him "Really? A bubble sort? Why?" Who ever uses a Bubble Sort after their first programming class? He didn't have time to implement anything better, he said. "But.. qsort is available in a library, isn't it? Just link it in, reference the header, and..? No?" He was shaking his head. "It would take too long to get it working, so I just used a bubble sort." So he wrote his whole own custom bubble sort routine, rather than..? I gave up.

    The rdbms is your friend. It's very good at making efficient use of memory while doing an efficient job of searching and sorting (and facilitating relational relationships, dealing with concurrency issues, et etc and so on and so forth). That's why it was made. Sure, it stores data in files on the filesystem (although in some cases, in some configurations, they don't actually use filesystem files, rather they use block device nodes to access disk partition/volumes directly), but why create your whole own custom indexing system when the rdbms already gives you a better one? If you need to do something the rdbms was made to do, don't reinvent the rdbms to do it. It is already there to help.

    And Pleeease don't use an ORM. SQL is your friend, too. It's not hard to learn or use. It's not hard to maintain. It's declarative, clearer, and does a lot more with a lot less code than most of the rest of your code. SQL is great at what it does. ORM's generate SQL on the fly, which spends a bunch of really unnecessary cycles and means that you can't tune your SQL directly, or recognize it very easily when you're looking at what's (taking so dern long) running in the db, and.. there's a long list of other really terrible problems with ORM's. Just please don't use one.

Leave a comment on “We Don't Need No Stinkin' Database”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article