4 ms·

Newer hackers should know that parsing text files is a good alternative to using a database for many web apps, esp. in early stages.

by javert 17y ago

patio11 17y ago
Coming from a Java & Rails background, with my SQL being non-existent as of 2 years ago and only fair to middling today, I'd have to disagree with that for anything but trivial one-day apps. (And with SQLite around as an option I'd be reluctant even then.) You can use Rails for simple apps without learning SQL or worrying about your database's internal black magic. It is about as simple as @user = User.find(id) -- you don't have to worry about what poor animal had to have its entrails removed to get that record. You also didn't have to: 1) implement a parser (which is going to break the first time you add an I-can't-believe-its-not-a-column) 2) write a migration framework (so that you can port your data files when you break your parser) 3) deal with simultaneous access (which, lets be honest, you're going to either ignore or whip up an implementation of locks which is exactly as buggy as every other programmer's implementation of locks which is why locks are right up there with crypto in the pantheon of Here Be Dragons, Use The Library) 4) build your own structure for separating your I/O from your application logic (which will asymptotically approach ActiveRecord, except with less features and more suck) 5) do a rewrite and/or significant rearchitecturing when you eventually are forced to move up to a database
- lsb 17y ago
  SQLite is targeted, actually, at specifically those people who would just use fopen() to store data: http://www.sqlite.org/whentouse.html http://www.sqlite.org/whentouse.html
mahmud 17y ago
Parsing? I don't think that's the point of using basic serialization; it's not that you need to write-out and parse-in your data structures manually, it's because your language already provides the means to serialize all the datastructure you use, without having to bolt a relational model on to it. For example, Lisp provides the PRINT-OBJECT method which you can specialize to "print" CLOS objects anyway you like; I use a tiny transactional object store to READ and WRITE the data structures into disk without worry (rucksack, which kicks butt btw) however, to display them, I specialized PRINT-OBJECT method for various views: ; print as html table print-object ((object user-data) (stream http-stream)) ; print as CSV print-object ((object user-data) (stream csv-stream)) ; display on the console, for interactive use (defmethod print-object ((object user-data) stream) (with-slots (id name email last-login) object (format stream "~a ~a ~a ~a~%" id name email last-login))) The result is that I can do (print (make-instance 'user-data)) and it would print on one line, if I am interacting with it; or it would print as an html table, if I refresh my browser and the printing code is invoked by the page handler; or it would print as semi-colon separated CSV values if I am printin out to a file. The parser and reader are already provided by the language, you just tweak them when you want to fit your aesthetics without loss of functionality.

Newer hackers should know that parsing text files is a good alternative to using a database for many web apps, esp. in early stages.

by javert 17y ago

Newer hackers should know that parsing text files is a good alternative to using a database for many web apps, esp. in early stages.

patio11 17y ago

Coming from a Java & Rails background, with my SQL being non-existent as of 2 years ago and only fair to middling today, I'd have to disagree with that for anything but trivial one-day apps. (And with SQLite around as an option I'd be reluctant even then.) You can use Rails for simple apps without learning SQL or worrying about your database's internal black magic. It is about as simple as @user = User.find(id) -- you don't have to worry about what poor animal had to have its entrails removed to get that record. You also didn't have to: 1) implement a parser (which is going to break the first time you add an I-can't-believe-its-not-a-column) 2) write a migration framework (so that you can port your data files when you break your parser) 3) deal with simultaneous access (which, lets be honest, you're going to either ignore or whip up an implementation of locks which is exactly as buggy as every other programmer's implementation of locks which is why locks are right up there with crypto in the pantheon of Here Be Dragons, Use The Library) 4) build your own structure for separating your I/O from your application logic (which will asymptotically approach ActiveRecord, except with less features and more suck) 5) do a rewrite and/or significant rearchitecturing when you eventually are forced to move up to a database

lsb 17y ago
SQLite is targeted, actually, at specifically those people who would just use fopen() to store data: http://www.sqlite.org/whentouse.html http://www.sqlite.org/whentouse.html

mahmud 17y ago

Parsing? I don't think that's the point of using basic serialization; it's not that you need to write-out and parse-in your data structures manually, it's because your language already provides the means to serialize all the datastructure you use, without having to bolt a relational model on to it. For example, Lisp provides the PRINT-OBJECT method which you can specialize to "print" CLOS objects anyway you like; I use a tiny transactional object store to READ and WRITE the data structures into disk without worry (rucksack, which kicks butt btw) however, to display them, I specialized PRINT-OBJECT method for various views: ; print as html table print-object ((object user-data) (stream http-stream)) ; print as CSV print-object ((object user-data) (stream csv-stream)) ; display on the console, for interactive use (defmethod print-object ((object user-data) stream) (with-slots (id name email last-login) object (format stream "~a ~a ~a ~a~%" id name email last-login))) The result is that I can do (print (make-instance 'user-data)) and it would print on one line, if I am interacting with it; or it would print as an html table, if I refresh my browser and the printing code is invoked by the page handler; or it would print as semi-colon separated CSV values if I am printin out to a file. The parser and reader are already provided by the language, you just tweak them when you want to fit your aesthetics without loss of functionality.