On Thu, May 7, 2015 at 12:25 PM, John McKown <john.archie.mckown at gmail.com> wrote:
> On Thu, May 7, 2015 at 10:01 AM, Stephen Chrzanowski <pontiac76 at gmail.com> > wrote: > > > Although I can understand the sarcasm you're sending out, a client/server > > infrastructure would be an interesting task for SQLite to do, but to > answer > > the OP, no, SQLite isn't inherently designed to be a client/server. > > > > ?And not really that difficult. Embed SQLite into some "server code" to > which a client connects, probably via TCPIP or some other IPC method.? The > client connects to the server, which uses the embedded SQLite to access the > appropriate SQLite data base file. I would guess that the server could even > be multi-threaded with each thread controlling a separate SQLite data base > file. > > If you're referring to a central repo, then yeah, SQLite could be made to compete with other major DBMS systems. But the pre-coffee "me" was thinking more about a type of synchronized clustering type of technology, in that, each client running the "server" has not only a copy of the database it can access 100% locally, but, shares the results of each transaction done, both in-bound and out-bound, via TCP. So even if there is a disconnection on the network, say, a laptop goes home for the evening and not hooked into a VPN, work can still be done on that database. The client software treats the database as its only source, but, on the "server" side of things, it is checking to see if there are any other "servers" on the LAN and tries to make a connection to sync up any data that might be out there. Once the machine gets back into the office, sees that there are other clients out there, it can sync the data back to the other clients. The "client software" wouldn't have to be running UNLESS the client software is running the "server code" inside itself. Essentially, a multi-threaded application, where one thread does all client stuff, and another that does server stuff, but the application as a whole treats both threads as completely different entities, and establishes connections via normal calls. There are MANY things to be taken care of,such as data collisions, who has priority over the data, "full record locking" (As in all information about a particular subject, say, an insurance claim which would hold information about the customer, the policy details, comments about the policy, etc), and the such. It wouldn't be an easy task, no, but, the post-cafinated me thinks that with a TONNE of work, it can be done. And if I get bored when on night shift at work, I just might peddle at something like that in a language absolutely no one on this forum (Other than Bogdan) uses. > > > > > > But, think of how torrents work. Everyone is a server, everyone is a > > client. Everyone has a connection to every other database, but, it has > its > > own working copy to query against. If Client A updates a table, the > > statement is sent out to every other "server" it has a connection to. > Any > > differences in the data can be synced from one to another. Even with > > MySQL, the client has to pull the information it needs from the database > to > > get its information and work with it locally in RAM (usually) then push > the > > data back if there is anything to be done. Instead of the queries going > to > > a MySQL server, you'd be talking to a server sitting right on your > > machine. Any queries from any other clients are done in another > > process/thread to the server database. (I'm actually kind of getting > > excited about this kind of coding, honestly.....) > > > > ?I'm not an expert in this area, but your description sounds a bit like a > stored procedure to me. http://en.wikipedia.org/wiki/Stored_procedure > Basically, you define the "procedure" in the data base itself, and the code > runs on the server, perhaps even in the same process as the server. This > saves the cost of doing the data transmission / reception between client > and server. > > No, I'm talking about data stored in applications assigned RAM after the database communication transaction, outside of any database. So I make a query to the database, and whatever results come up are dumped onto a form, an array, or what have you. Work is done on the data, within the UI/Memory client, outside of the DBMS, then whatever data is affected is pushed back into the database. >From my course back in the early 2000s when I did training to be an MSDBA (Which I never did the actual certification for, unfortunately -- Money constraints), Stored Procedures can look and act like a view, but, have the knowledge of a language, variables and variable scope, and what not, to deal with information all within the engine of the DBMS, which means the client makes the request, the server/SP does the work, the server feeds the data back to the client. The SP has the ability to do any additional transactions to get the results, actually process the data, and then push the data out. For example, with MySQL and MSSQL, you can lock down a SP to the point where a routine can't be used by a user, but, you can write the SP so that depending on who the user is, the SP can decide if the user is allowed to see credit card information or not, and still allow all users to have access to the SP. In that example, the client can make a direct request "Whats the credit card number for this person?" and depending on the account privileges, the SP will look at the users connection credentials (Or what have you) and decide if it is a valid thing to provide, and if not, spit back either a blank string, or some sort of result to tell the user to SOD off, etc. Not to mention, given the credit card example, since all work is done within the database itself, if the user is not allowed to have access, credit card information WON'T be pushed out over the wire or air because that information is either not accessed by the database due to the constraints of the user, or, it at least never leaves the servers memory. > > > > > This isn't to say that this kind of infrastructure would be CRAZY to do, > > but it isn't impossible, and the hurdles to get it done can be overcome. > > So although a gas burning electric stove seems odd, getting the gas to > boil > > water to push the turbine to generate electricity to run the burners does > > fit the particular scenario. > > > > Well, that's "cheating" </grin> by marrying an electric generator with a > normal electric oven. And I do hope the burners have good thermal > insulation from the supporting wood frame. > > Cheating is what mechanics and software developers do best when they have the tools available. ;) True innovation is full of creative cheating styles and methods. Only after it becomes an acceptable standard of operations does it not count as cheating anymore. :]
