Diskussion:SAP HANA
Widerspruch in Geschichte und Verwendung
Im ersten Abschnitt ist die Rede von Kernkomponenten und im Abschnitt Verwendung wird von der ganzen Suite gesprochen. (nicht signierter Beitrag von 193.110.85.45 (Diskussion) 13:13, 28. Aug. 2013 (CEST))
Akronym
HANA bedeutet(e) "Hassos New Architecture". --130.75.186.13 17:28, 18. Mär. 2014 (CET)
Geschichte euphemisiert
Aus den öffentlichen Veranstaltungen/Vorlesung geht hervor, dass das DBMS seine Ursprünge in der Uni hatte. Sinngemäß äußerte sich Hasso dazu: 2006, die Studenten wollten etwas über neue Technologien lernen, wir hatten nichts und sahen einen Trend in Cloud und entwickelten eine In-Memory Datenbank.--Darktrym (Diskussion) 12:31, 27. Mär. 2014 (CET)
Verfügbarkeit für SAP Business Suit
Kann bitte jemand inklusive Quellenangabe aufnehmen, dass SAP am 10. Januar 2013 die Verfügbarkeit der gesamten SAP Business Suite on HANA ankündigte? Dieser wichtige Punkt sollte nicht unerwähnt bleiben. --212.255.120.46 23:03, 1. Apr. 2014 (CEST)
SAP Business One
Das Pordukt SAP Business One ist in der aktuellen Version 9.0 und 9.1 (aktuell im Rmap Up) für HANA verfügbar. Dabei wird unterschieden zwischen HANA-Analytics, bei der Auswertungen und Dashboards auf einer HANA betrieben werden, deren Inhalt im Hintergrund vom führenden SQL Server repliziert werden. Die zweite Stufe ist SAP Business One on HANA. In dieser Version wird kein SQL-Server verwendet, vielmehr geschieht die komplette Datenhaltung auf einer HANA. (Quelle: http://www.uniorg.de/de/sap-loesungen/sap-hana/sap-business-one-mit-sap-hana.html)--91.34.234.204 21:54, 30. Jun. 2014 (CEST)
SAP HANA Cloud Platform vs. In-Memory-Anwendung
Das ist doch der Widerspruch per se: "Cloud" und "In-Memory". SAP ist einfach unglaublich.
Stellt fest Harald Wehner (Diskussion) 20:34, 26. Dez. 2019 (CET)
Nachteile?
Sollte man nicht auch kurz die Nachteile erwähnen? Spaltenbasierte Datenbanken sind nicht neu, man hat das Konzept in den 70ern/80ern ausprobiert und nach sehr negativen Erfahrungen eigentlich aufgegeben.
Bei SAP HANA wären u.a. zu nennen 1) Gefahr von Datenverlust bei Systemabsturz aufgrund nicht-persistierter Änderungen 2) unzureichende Umsetzung des SQL-Standards wie bspw. Fehlen von Collations mit der Folge, dass man manuell Sortier- und Suchspalten vorhalten und pflegen muss 3) Bei großen Tabellen plötzliche, dramatische Einbrüche der Performance 4) Syntaktisch korrekte Select-Statement sind auf großen Tabellen nicht einfach nur langsam wie auf einem normalen RDBMS, sondern können gar nicht ausgeführt werden: Hana reagiert mit einer OutOfMemory-Exception. Das ist i.Ü. kein Zufall sondern ein generelles Problem von spaltenbasierten Datenbanksystem. In der Praxis bedeutet das: Eine Query, welche heute anstandslos funktioniert, kann morgen aufgrund einiger zusätzlicher Datensätze eine Exception werfen und einen Systemausfall verursachen. Natürlich könnte man grundsätzlich bei betroffenen Tabellen stattdessen auf das ebenfalls implementierte zeilenbasierte Modell umstellen, allerdings kommt dann sofort der nächste Nachteil zum Tragen: Mangelhafte Unterstützung für zeilenbasierte Tabellenmodelle mit unzureichender Performance. So gibt es eine lange Liste von Features ausschließlich für das spaltenbasierte Modell, angefangen von Identity-Spalten (Auto-Increment) bis hin zu Komprimierung und Verschlüsselung. Das heißt, die sind zwar vorhanden in der Praxis jedoch unbrauchbar. --2A04:4540:5F06:6100:D45F:AE5:9C71:D1F9 11:02, 18. Feb. 2021 (CET)
