• Steve (unregistered) in reply to SeekerDarksteel
    SeekerDarksteel:
    Of course this is coming from the same person who couldn't stop laughing for 5 minutes after thinking about the idea of pcAnywhere'ing into a remote box, then pcAnywhere'ing back into my own box.  Speaking of which, I need to try that sometime. 

    tried that: it's like looking into 2 mirrors standing opposite of each other: endless repitition. (and a lot of network traffic) :-D

  • woohoo (unregistered) in reply to utunga
    utunga:
    Hey why not! OK its certainly a WTF but I don't think anywhere near as bad as some of the mind numbing horror that you will see on this site on occasion. Basically what he's doing is writing an in-memory database. If he was looking for a .NET equivalent, he may, yeah have to use some of those 'Class' things but for the rest of it maybe the closest equivalent would be Bamboo Prevaylance. Whacky, and obviously not a programmer but there is something appealing about it I'm sure. As someone said, the real wtf is that he was not using a hashtable, or should i say, Scripting.Dictionary

    "in memory database"? wait.. I must've missed out on something... I thought that ASPs are files which are stored in a filesystem...

    come on. this is really the single most stupid thing you can do, 'cause this is not "in memory" but just "flat-file" storage, which is not really notorious for optimal performance when retrieving information...

    captcha: craaazy - oh yes...

  • woohoo (unregistered) in reply to ammoQ
    ammoQ:
    hmm... it's hardly worse than any other flat-file storage method (XML, CSV etc.). Of course, not using a real database counts as a WTF in most real world applications; but it's hard to judge if this "database" with a few hundred records makes it worth the effort. Most applications in this world  can be made more sexy by throwing lots of cash at it. Buy me a database server, buy me a middleware, send some consultants for 250 USD/h and we will make the most buzzword compliant system in the world. But please never mention the ROI.

    sorry, but it is worse. much worse.

    need some examples?

    • in xml you could at least leverage some kind of type-saftey. moreover the data could be used by any other xml-aware application.
    • even with simple flat text files (csv or whatever) you at least can react dynamically to changes in the number of rows and/or columns respectively.
    • also, both would be much more readable to someone not fluent in ASP syntax.

    arrays are language constructs, not a file format or whatever. constructing array code "on the fly" - thus hard-coding the dimensions - and all this inside of a special technology dependent file format like ASP, that is the real WTF here.

    nothing to be said in principle against file storage vs. DB storage if it is used in the right context (considering cost, data volume, performance, format, future-proofness (!) etc).

    captcha: kungfu -- huh-hah!

  • woohoo (unregistered) in reply to Omnifarious
    Omnifarious:
    mcrbids:
    I've used solutions like this where part of the spec is that no flavor of SQL is available, and there's a need to store complex sets of data in files. He at least abstracted maintenance into a single, uniform method!

    So, really, what's the WTF? Please explain. No, I'm not satisfied with "ooh, the eyes!", either.

    Yes, you end up with limits on storage size, and SQL is the preferred choice. But, with the limitations mentioned above, what's the "non-WTF" answer to this kind of problem?

    Seems to me that the WTF here is a programmer unable to challenge himself, and perhaps too dependent on alcohol.

    I rather agree with you. The main problem this has is the lack of a decent way to query it. But that may not have been important for the application. Given the size of the table, I'm guessing it probably isn't. One thing you could do if you wanted to wow the original programmer and lead him to a better way of thinking is to change the code so it automatically loaded the array from a real database at startup. Then no self-modifying code would be needed to maintain it. I have, in fact, seen some important small domain tables in larger setups handled in just this fashion. And it would be a way for the original programmer to get his feet wet with a real database without having to plunge in head-first. I truly don't think this is so bad. But, the original programmer clearly needs to lose the fear of complex database tools that inspired him to write this in the first place.

    no. this is bad. apart from issues like scalability, multithreading etc. when using flat-file storage, he should've used at least XML, CVS or the like. coding data as a language-specific source code construct is just plain dumb, no matter under which circumstances.

    • XML would provide some basic searching capability and type-safety
    • CVS would be at least more readable (for humans as well as for other apps)
  • woohoo (unregistered) in reply to ammoQ
    ammoQ:
    Anonymous:

    it wouldn't be so impossible to keep the NO SQL part but add significant structure

    Class product     Public manufacturer     Public name     Public code     Public image     Public description_html     Public price     Public weight     Public flag End Class

    This counts as an attempt to do the wrong (Q&D) thing right. IMO not a good idea.Eighter keep it quick&dirty, so at least it's as simple as possible; or do the right thing - use a database.

    quick&dirty: flat files (XML, CVS, ...)

    dumb&dirty: using a language-spedific source code construct (i.e. array) to store data

    captcha: ewww (how extremely well-fitting ;o)

  • Kuba (unregistered) in reply to Anonymoose
    Alright, how about:

    The real WTF here is that guy thinks his solution is better than a database.

    He was not restricted from using SQL, as far as we know.

    Ekhm, the approach is OK, it just wasn't the right language to use. In LISP, there would be nothing wrong with it. He wouldn't even need to generate any source -- simply keep the data structures around and print them out to a file. Heck, the file could be compiled at runtime to speed up loading, if modifications were less frequent than loads (likely). LISP provides a standardized way of printing out any "reasonable" contents, such that it's valid LISP source and can be read back.

    Easy does it.

    pirates: arrr!

  • Kuba (unregistered) in reply to woohoo
    coding data as a language-specific source code construct is just plain dumb, no matter under which circumstances.

    Not in LISP. In fact, for quick-and-dirty projects, I wouldn't mind storing slowly changing data as a simple LISP source. Common Lisp provides a way to dump any reasonable data out as the source, and a way to read it back. There's also a standard way to compile said source so that it loads quickly.

    Some LISPs provide workspace save/restore, which would speed it up. It's like object prevalence to the max, in a platform that's soon to be half a century old. Progress, my ***.

  • Kuba (unregistered) in reply to JohnO
    I can think of no set of circumstances under which I would call the Storrary Engine an acceptable solution.

    Stuff like this is done daily in production LISP code and it usually works pretty well. For me, it works great in embedded real-time systems where for realtime-qualified data you'd have to write a realtime-qualified database. We're not talking about big iron like banking: the datasets are small (about 18MB), but a lot of query functionality equivalent to a page+ of SQL has a 0.5ms hard time window.

    I have quite a bit of low-consing embedded code where quite a bit of data is being compiled into the final binary straight from "sources" which are S-expressions.

    Said sources are all generated, and represent static configuration data and such.

    Data that's variable, but needs to be initialized, is handled similarly, just that the resulting binary objects end up being copied to RAM at system initialization, and are sent out to flash memory as needed (at transaction points etc). It's binary, but for debugging the flash can be printed out as S-expressions and used to troubleshoot on the desktop. Very handy, and all provided for by the LISP platform.

    LISP ninjas ;)

  • TwelveBaud (unregistered)

    I really hope that the programmer in question doesn't discover "System.Reflection.Emit", or even worse "System.CodeDom" and "System.CodeDom.Compiler" and friends.

  • Jimmyanten (unregistered)
    Comment held for moderation.
  • Derekwaisy (unregistered)
    Comment held for moderation.

Leave a comment on “The Storray Engine”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article