[TYPO3-dev] Request for cleanup of typo3 database schema

[R. van Twisk]

Martin Kutschker wrote:
> R. van Twisk schrieb:
>   
>> I might be old fashioned, but it's really old fashioned that an 
>> enterprise CMS uses MySQL by
>> default with MyISAM storage (which was recently changed to InnoDB) and 
>> cannot
>> handle at least 2 or 3 other big RDBM's out of the box (Oracle, MS-SQL, 
>> PostgreSQL)
>> without hitting quite a number of roadbumbs to get it resolved and a 
>> huge speed
>> impact because of the use of AdoDB and other translation layers (DBAL).
>>
>> The CR tries to solve that which is a good thing.
>>     
>
> So does DBAL. There are many ways to move the burden of writing DB 
> specifc SQL queries from the developer.
>   
I don't believe the a CR solves teh same problem as DBAL.

in my opintion
 - CR solved the problem of storing and retrieving data from and to a 
repository. In a CR anything can be stored (images, documents, binary 
files, newss records, guestbook records etc... possible relations 
between records can be added).
   it will generally contain a API to retrieve and store data.
 - DBAL solves the problem of transparently accessing database tables

> But I'm complaining when JCR reqires Xpath support and TYPO3 solves this 
> by emulating it. If your app needs Xpath then choose a DB that supports 
> it. THe JCR may have an API for that fine, but in case the DB doesn't 
> have it, it should simply throw an error.
>
> The Xpath feature could be detected at runtime with a capability API call.
>   
full ack...
>   
>> However I also do agree that we need to have a good API for Db access in 
>> a fairly transparent way
>> and RAW way. This to access external databases and to handle data that need
>> raw speed of the DB. Like the last XX of data YY problems. Something a 
>> CR might not always be able to solve quickly enough.
>>
>> What other options do we have for JSR-170?
>> We need at least:
>>
>> CMS specific:
>> 1) A concept of worksspaces
>> 2) A concept of versions
>> 3) A concept of history
>> 4) A concept of multi-langual
>>
>> Web specific:
>> 1) A concept of multi-domain
>> 2) a concept of user and group rights
>> 3) A concept of time rights.
>> 4) Caching mechanism
>>
>> Just to name a couple that crosses my mind...
>>
>> If we make the above with 'RAW' SQL,
>> so that every extension is responsible for the above and properly other 
>> items.
>> Then I can promise you we will gain no step into the feature then we are 
>> right now.
>>     
>
> IMHO many extensions are "list type extensions". They do have single 
> items, but many views are lists. As they usually come with relations and 
> stuff SQL is fine to handle such stuff. Will JSR-170 store tt_news item 
> in flat files? I have been told: JSR will know best how to handle this. 
> I doubt that. How much AI shall this wonder thing have built in?
>   
I think it would not be a bad idea to store these kind of records in a CR.
However, like I mention above relation between records need to be resolved
as well as other 'class' problems. We don't want to call the CR 1000 of 
times
just to generate on page. Basically we want to ask the CR:
Give me the content for this and that page for these and that conditions.
Unfortunately I don't know JSR 170 well enough to get a good feeling for 
myself
if it will work for typo3 or not. I know people here do have experience 
in some degree.

However, when JSR 170 was created, and at least  group of people are 
using it, it can't be really that bad?!?!


I just don't ave experience with JSr170, so I will not talk about it...
I just do feel that typo3 will benefit from some CR to solve common problems
like versioning, workspaces, history etc etc etc.

We all benefit from SVN, do we???

In the mean time I just keep my head spin, and if I have a good idea 
I'll let you all know.

Ries