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

[R. van Twisk]

Dmitry Dulepov wrote:
> Martin Kutschker wrote:
>   
>> I'm old fashioned - I want my direct DB access, not 200 layers in 
>> between. Especially as we're currently discussing in other threads DB 
>> finetuing of DBs, it's extremely irritating if SQL in TYPO3 5.0 is so 
>> "remote" from the admin and developer.
>>     
>
> I already told several times in the past that using jcr-170 in typo3 
> would not give any advantage. This technology does not work well even in 
> java (its native environment) but 5.0 team wants to use it from php. I 
> did not get any real argument why it should be done.
>
> I am old fashioned too.
>
>   
I think any method to get an retrieve 'CMS' sort of data
should have an API, period.
whether it's a CR or anything else, we need to have an API
to store and retrieve data in an abstract way. It can handle maby things
like workspace, versioning etc etc.... something that is difficult from
using RAW SQL calls.

it's not for nothing that when workspaces was introduced, may extension 
are not and still
not compatible with it... That simply means that data access was not 
abstract enough.
This is by NO means a complain, I understand it and it is a evolution of 
development.

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.

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.

just my 2 cents,
Ries




-- 
Ries van Twisk
Freelance Typo3 Developer
=== Private:
email: ries at vantwisk.nl
web:   http://www.rvantwisk.nl/freelance-typo3.html
skype: callto://r.vantwisk