US Firm Oracle Pulls Plug on Eskom

r00igev@@r said:
Oracle licensing has always been a ripoff. Nothing new. Fascinating is that people cannot wean themselves off it.
Click to expand...

Yeah, always.

Hell I remember nearly 20 years ago seeing their licensing terms and thinking WTF back then. It was monumentally complex and a ripoff even then. Hell any of the DB Solutions out there with enterprise grade support are not cheap but I think Oracle is towards the top end of "not cheap"

Corporates do get comfortable with a major platform like Oracle though, and end up choosing it because they have the inhouse skills to manage and maintain it even if it isn't necessarily the best of breed platform for a specific product, but the product does run on Oracle.
 
r00igev@@r said:
Oracle licensing has always been a ripoff. Nothing new. Fascinating is that people cannot wean themselves off it.
Click to expand...
Look, it works. But it's expensive. SQL does the same job at a fraction of the cost (and that is expensive).
 
ToxicBunny said:
Yeah, always.

Hell I remember nearly 20 years ago seeing their licensing terms and thinking WTF back then. It was monumentally complex and a ripoff even then. Hell any of the DB Solutions out there with enterprise grade support are not cheap but I think Oracle is towards the top end of "not cheap"

Corporates do get comfortable with a major platform like Oracle though, and end up choosing it because they have the inhouse skills to manage and maintain it even if it isn't necessarily the best of breed platform for a specific product, but the product does run on Oracle.
Click to expand...
Oracle's age is showing. Even IBM has been more innovative than the bunch of overpriced mobsters.
 
r00igev@@r said:
Oracle's age is showing. Even IBM has been more innovative than the bunch of overpriced mobsters.
Click to expand...

I haven't played in depth with Oracle in ages, but on the face of it I would totally agree with you, Oracle just hasn't seemed to bring anything amazing to the table that gets people excited in quite a long time that I've been aware of.
 
And they paid guptas billions for zero services!! Go figure... OK obviously not the new guys. But it's a cANCer in the country
 
Transactional data does not need relation databases like the Oracle db. This data can be kept in a no-sql store for a fraction of the price - aka cloud data, I think this is why they want to create a new cloud.
 
Benedict A55h0le said:
Transactional data does not need relation databases like the Oracle db. This data can be kept in a no-sql store for a fraction of the price - aka cloud data, I think this is why they want to create a new cloud.
Click to expand...

It doesn't necessarily need to be in a relational database, correct.

But a no-sql store doesn't necessarily provide the same performance as a relational database, and also the software front end that provides all the business logic (Maximo as an example) doesn't necessarily support a no-sql store so then a relational database would be a requirement to use the product.

You cannot unfortunately look at the database/datastore in isolation and go "Relational databases are shyte, just use a no-sql store, or some other technology" you have to look at the entire technology stack as well as the business stack.
 
ToxicBunny said:
It doesn't necessarily need to be in a relational database, correct.

But a no-sql store doesn't necessarily provide the same performance as a relational database, and also the software front end that provides all the business logic (Maximo as an example) doesn't necessarily support a no-sql store so then a relational database would be a requirement to use the product.

You cannot unfortunately look at the database/datastore in isolation and go "Relational databases are shyte, just use a no-sql store, or some other technology" you have to look at the entire technology stack as well as the business stack.
Click to expand...
I am willing to bet my left nut that the bulk of this transactional data is suitable for no-sql, just like with telecoms data - flat and not relational. Transactional elec data must 1stly go into a no-sql store, thereafter processing maybe smaller relational dbs are needed.
 
Benedict A55h0le said:
I am willing to bet my left nut that the bulk of this transactional data is suitable for no-sql, just like with telecoms data - flat and not relational. Transactional elec data must 1stly go into a no-sql store, thereafter processing maybe smaller relational dbs are needed.
Click to expand...

You can bet whatever you want...

The reference to Maximo in the article puts a very specific requirement on Eskom in terms of the supported database systems, and none of them are no-sql stores.

I would also be relatively sure that whatever other software packages are used for load monitoring at the stations etc all have very specific database requirements that don't support no-sql stores.

So to win your left nut bet would require a complete rewrite of the entire stack of software that Eskom currently uses for its generation monitoring (which is almost definitely a small subset of the entire power generation management platform, so then a rewrite of that whole stack effectively), as well as a rewrite of a piece of software to replace Maximo. Just to use a no-sql store.
 
Benedict A55h0le said:
Transactional data does not need relation databases like the Oracle db. This data can be kept in a no-sql store for a fraction of the price - aka cloud data, I think this is why they want to create a new cloud.
Click to expand...
Good luck trying to do things like real-time network fault path monitoring and fault dispatching on a non-relational db.
 
ToxicBunny said:
But But, no-sql is teh shiznit, and it free!!!!!
Click to expand...
...and you can snap your fingers and tomorrow all of your applications will interface with it nicely with no further application development required. :ROFL:

It's pretty clear how few people on here with technical knowledge understand the applicability of the solutions they are proposing in regards to very specific use-case systems or the change management (+associated time and cost) required to implement those solutions.
 
Iwojima said:
...and you can snap your fingers and tomorrow all of your applications will interface with it nicely with no further application development required. :ROFL:

It's pretty clear how few people on here with technical knowledge understand the applicability of the solutions they are proposing in regards to very specific use-case systems or the change management (+associated time and cost) required to implement those solutions.
Click to expand...

Yup, its very very clear.

Guys who work on relatively small scale systems where swapping out a data platform is not a monumental multi-year project with untold regulatory and compliance pitfalls that could derail the project 18 months in as well...
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X