David Ziffer (11/1/2010)
Jeff Moden (10/31/2010)
David Ziffer (10/30/2010)
I certainly would load rows into a single table as a group, but even those insertions must be done through individual calls to the RAP insertion procedure.... If you need to insert a "group" of rows, it just shouldn't be done one row at a time. As with anything else, "It Depends" but, comparatively speaking, it's much too resource intensive to insert groups of rows in a RBAR fashion. It would be really cool if your product knew how to receive and insert more than one row in a set based fashion.
Jeff: I agree with you and I just haven't had the time how to figure out now to more efficiently do multiple-row insertions yet. Perhaps this will be a future improvement. For the moment, the single-row implementation does serve as an example of how to simultaneously update a "current" and "archive" table.
With regards to RBAR: it may be true that my current implementation of RAP does cause agony for the computer, which must handle insertions at the row level. However the "A" in RBAR suggests that there is perhaps a human who is in agony somewhere. One of the main points of RAP is that the programmer doesn't have to think about any of this stuff at all. At the application level, the programmer just says to RAP's ORM: "write whatever you have." The programmer doesn't think about rows or columns or even tables. In fact, the programmer doesn't have to care about implementation at all (unless of course RAP is too slow for him and we are forced to start programming for more efficiency).
My main purpose here is to illustrate what can be done from a functional perspective, if only we would all stop thinking at the component level and start implementing consistently at the system level. I do not presume that the algorithms I present here are the most efficient possible and I am happy for people's suggestions as to how I might improve RAP at any level - because I do want it to be used in real production systems.
So I thank you for your input and I will almost certainly look into this issue. But once again, the point here is to throw down some sort of prototype for doing things systematically.
Heh... there're a couple of dozen people on this site alone who are capable of pulling off huge multi-row inserts from a GUI via a stored procedure. If you'd care to throw some $$$ in their direction, I imagine they'd be happy to write the code for you.
So far as the rest of it goes, I understand that your goal is very well intentioned and making it so developers don't actually need to think about such drudgery as writing insert code. But that's not a real change because a lot of them don't think of it as it is. Your product is an improvement for them because you've perpetuated the notion that a developer doesn't actually have to think about the harm they may be causing to the database, the underlying server, or even the "pipe". You've also given them something to blame because you've also removed the responsibility.
What would really be cool is if a product like this actually did something better than a developer... like figuring out the proper way to insert groups of rows. My apologies for how blunt that sounds but it would nice.
--Jeff Moden
Change is inevitable... Change for the better is not.