pat at netburp
Jan 15, 2003, 11:19 PM
Post #19 of 42
(3534 views)
Permalink
|
Uhhhh....what? I don't *thinik* there's a question of moving the data
out of mysql or *A* database anyway , I think the debate has been...
a) should the backend provide an interface to the database
or
b) should the frontend connect to the database directly
Security wise, a makes more sense, but how secure do you want your
recordings of M*A*S*H to be???
In most situations all connections would be behind a firewall
hopefully, and connecting to the db directly, and even through an api
would be less costly than asking for the info through the backend.
Personally, I don't care who knows that I record junkyard wars, but
ymmv. ;-)
Pat
Joseph Stump wrote:
> New to the list, but I thought I should chime in. MySQL is a well
> known DB, which allows, if nothing else, widespread addon/module
> development. For instance, once I have my MythTV box up and running I
> plan on writing a WAP module in PHP/MySQL because I'm sure I can
> figure out the table structure, etc.
>
> IMO MySQL is rather simple to set up - more so than most. Yes it would
> be easier to embed it into the backend, but you would end up hindering
> innovation in the end because the standard/files wouldn't be as open
> and widely understood.
>
> --Joe
>
>
> On Thursday, January 16, 2003, at 12:29 AM, James Sleeman wrote:
>
>> Bruce Markey wrote:
>>
>>> James Sleeman wrote:
>>>
>>>> I think that Stephan has a point. I find applications that require
>>>> mySQL to be installed and create database/tables etc are a pain -
>>>> namely because it's generally not necessary for the software to
>>>> have such a hefty (even if mySQL isn't exactly hefty) requirement,
>>>> it adds to the complexity for the system needlessly in most instances.
>>>
>>>
>>>
>>> But not all instances, agreed? In this case, there are 1000's
>>> shows with multiple fields of information, lists of recordings,
>>> lists of titles to search for to be recorded, etc.
>>
>>
>> True yes, not in all cases.
>>
>>> Without a
>>> database, the data would need to be stored in flat files and
>>> you'd need to parse, error check, lock while writing... Oh,
>>> write a new database. That would defiantly be a pain and
>>> add complexity.
>>
>>
>> Obviously a (capable) database is required, and it is not an
>> efficient use of developer time to reinvent the database, hence my
>> suggestion of a lightweight embeddable database as a default engine
>> (eg SQLite as I noted, which I think would be quite capable of
>> handling the data requirements of mythtv, easily so) which gives you
>> most of the benefits of a big engine such as mySQL without the setup
>> & administration & overhead.
>>
>>> the choice of mySQL was because it is ubiquitous.
>>
>>
>> Only if you have need for an RDBMS, if you don't then why should myth
>> require it be installed when a lightweight embedded solution may be
>> better suited to the application.
>>
>>>> To put it simply, I think the frontend should only have to know how
>>>> to contact the backend, and that's all - everything it needs
>>>> (video, program listings etc) it asks the backend to provide to it.
>>>
>>>
>>>
>>> To what end? What problem are we trying to solve? The
>>
>>
>> Abstraction -- PostGres != mySQL != MSSQL != jetSQL etc, there are
>> minor (and major) differences between these systems, by abstracting
>> the DBMS connectivity to an extendable class it means that the
>> proliferation of SQL and exceptions to SQL is limited to within that
>> one class.
>>
>> Simplification -- The less connections between frontend and backend,
>> the simpler it becomes, for developers and users alike. Ask yourself
>> this, if you were the frontend, why should you care about the
>> database driving all this, all you care about is what the backend
>> tells you and what you tell the backend.
>> With multiple developers it becomes even more so, if a developer
>> working on the backend comes up with some new stuff in the database
>> engine (whatever that shall be) he shouldn't have to describe all
>> these low level details to front end developers wanting to use this
>> information, they should just say to the backend - "Hey, I want this
>> information" and the backend gives it to them after doing "things" to
>> the database, if another developer comes along developing something
>> else, they can also just ask the backend for the information, less
>> duplication of code, less places for things to go wrong.
>>
>>> The frontend can make the query (from the same library code) and cut
>>> out the middleman.
>>
>>
>> Yep, and I can go and milk a cow if I like and I cut out the milker,
>> truck driver, milk processing company, bottlers, and milk man - but
>> I'd much rather not know how my milk gets to me, all I care is I give
>> money to the milk man and he gives me milk all nice and ready to
>> drink. If I'm, the front end, I could find out what database we're
>> using, open a connection to it, select from the right table, being
>> careful to make the select correct, etc etc but I'd much rather not
>> know the gory details, I'd prefer to just ask a backend -
>> backend.getListOfShows(channel, from, to), or
>> backend.deleteThisShow(showID) or backend.recordThisShow(showID) or
>> backend.streamMeShow(showID) you get the idea.
>>
>> ---
>> James Sleeman
>>
>>
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev[at]snowman.net
>> http://www.snowman.net/mailman/listinfo/mythtv-dev
>>
>>
>>
> --
> Joe Stump - joe[at]joestump.net
> http://www.jerum.com
> "Software never has bugs. It just develops random features."
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev[at]snowman.net
> http://www.snowman.net/mailman/listinfo/mythtv-dev
|
1
