AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Empfehlung für SQL-Datenbank

Empfehlung für SQL-Datenbank

Ein Thema von udo888 · begonnen am 6. Sep 2024 · letzter Beitrag vom 9. Sep 2024
Antwort Antwort
Seite 1 von 2  1 2   
omnibrain

Registriert seit: 11. Nov 2022
81 Beiträge
 
Delphi 11 Alexandria
 
#1

AW: Empfehlung für SQL-Datenbank

  Alt 6. Sep 2024, 21:08
Wenn du praktisch nur Delphi nutzt, dann schau dir mal NexusDB an. Integriert sich perfekt in Delphi. Du kannst die DB wenn du ein Stand-Alone-Programm hast als "embedded DB" nutzen, sparst dir also den Server.
Oder du nutzt den mitgelieferten (oder nach Bedarf von dir angepasste/erweiterten) Serverprozess. Entweder als "einfaches" Programm das gestartet wird oder als Windows-Service und greifst entweder lokal auf dem gleichen Computer oder über das Netzwerk zu.
In der Pro-Fassung bekommst du den kompletten Source-Code also für die Client-Komponenten und auch für den Server. Lizensiert wird pro Entwickler.
https://www.nexusdb.com/support/index.php

Falls du nicht nur Delphi einsetzt gibt es von Nexus auch einen PHP- und .Net Connector und zusätzlich von Devart einen ODBC-Treiber. Jedoch würde ich dann (insbesondere wenn noch andere Technologien dazu kommen) eher auf PostgreSQL setzen und PgDAC oder gleich UniDAC nutzen.
  Mit Zitat antworten Zitat
Benutzerbild von haentschman
haentschman

Registriert seit: 24. Okt 2006
Ort: Seifhennersdorf / Sachsen
5.431 Beiträge
 
Delphi 12 Athens
 
#2

AW: Empfehlung für SQL-Datenbank

  Alt 7. Sep 2024, 08:04
Moin...

@TE

Am Ende des Threads wirst du nicht schlauer sein...weil jeder seine Vorlieben herausstellt. Am Ende zählt: die Anwendungsanforderung, Kosten, Installation, Wartung, Delphi Komponente. Auch eine überdimensionierte Datenbank ist schlecht. (Oracle für eine Adressverwaltung )

[meine Meinung]
Ich bin Firebird Fan , obwohl ich beruflich MSSQL benutze. (wegen Replikation).

Vorteile Firebird:
* kostenlos für immer!
1. Setup klein (25MB) und schnell installiert https://firebirdsql.org/en/server-packages/
2. mehrere Server parallel betreibbar unter verschiedenen Ports (config)
3. die Datenbank ist nur EINE Datei (nicht wie NexusDB, MSSQL, MySQL, Paradox)
4. die Datenbank ist sowohl mit dem Server als auch Embedded nutzbar (der Treiber (Hosteinstellung) gibt die Verwendung vor)
5. die Datenbank ist einfach kopierbar z.B. auf USB Stick ( sollte man aber nicht im laufenden Berieb machen (verbunde User und deren Schreibvorgänge))
6. Backup / Restore ist einfach
7. Zugriff über FireDAC(ab Enterprise für Server, sonst nur lokal), UniDAC, IBDAC, ZEOS(kostenlos)
8. Datenbank Tool: https://dbeaver.io/
9. vernünftige Dokumentation https://firebirdsql.org/en/firebird-rdbms/

...viel Spaß beim Entscheiden.


Info MySQL Lizenz Falle:
Zitat:
Eine Commercial License von MySQL wird erst dann benötigt, wenn man seine Software an dritte Verkauft und
die eigene Software sich nicht auf die GPL Licencse gründet!
https://www.delphipraxis.net/83913-m...ne-lizenz.html

Zitat:
hatte in Delphi noch keine richtige SQL-Berührung
Tipp für SQL in Delphi:
1. Verteile die Queries nicht auf die Forms.
2. Querys, und die Connection, gehören auf ein Datenmodul oder dynamisch in eine Unit. (bei mehreren Datenbanken jeweils eins, Umschaltung über ggf. Interface oder Instanz)
3. evtl. die SQL Texte nicht in der Query sondern extern in einen Ordner speichern und dann entsprechend der Datenbank der Query zuweisen. Erleichert ggf. den Umstieg auf andere Zugriffskomponenten.

Geändert von haentschman ( 7. Sep 2024 um 09:39 Uhr)
  Mit Zitat antworten Zitat
jsheyer

Registriert seit: 9. Jun 2005
Ort: Jüchen
90 Beiträge
 
Delphi 10.4 Sydney
 
#3

AW: Empfehlung für SQL-Datenbank

  Alt 7. Sep 2024, 11:07
Ich bin auch bekennender Firebird Fan, ich arbeite auch mit vielen anderen Datenbank Systemen, aber Firebird ist und bleibt für mich unproblematischste Datenbank und das uuch unabhängig vom OS.
Der Firebird Server läuft bei uns unter Linux, womit dann auch das OS keine Probleme bereitet.
Und wir haben Datenbanken die teilweise knapp 1 TB groß sind mit Datenmengen im Milliarden Bereich.
Und sie ist einfach super performant.
In Delphi verwenden wir auch UniDAC seit Jahren und sind absolut glücklich damit.
Jörg Heyer
  Mit Zitat antworten Zitat
TurboMagic

Registriert seit: 28. Feb 2016
Ort: Nordost Baden-Württemberg
3.038 Beiträge
 
Delphi 12 Athens
 
#4

AW: Empfehlung für SQL-Datenbank

  Alt 7. Sep 2024, 11:38
Hallo,

auch ich nutze Firebird.
Wenn man die Embedded Variante nutzen will muss man nur die entsprechenden Dateien mitliefern
und noch nicht mal was installieren.

FireDAC hat auch Komponenten für Backup und Restore für Firebird mit an Board.
Performance ist gut wenn man die übliche Optimierungsvorgehensweisen für relationale DBs
nutzt. Und wie bestimmt schon erwähnt ist es kostenlos.

An DB Pflegetools gibt's auch noch andere z. B.
https://www.sqlmanager.net/products/ibfb/manager
Davon gibt's auch eine kostenlose und trotzdem gewerblich einsetzbare Variante oder
inzwischen kann glaube ich auch HeidiSQL zumindest teilweise mit Firebird umgehen.
Grüße
TurboMagic
  Mit Zitat antworten Zitat
Benutzerbild von IBExpert
IBExpert

Registriert seit: 15. Mär 2005
695 Beiträge
 
FreePascal / Lazarus
 
#5

AW: Empfehlung für SQL-Datenbank

  Alt 7. Sep 2024, 18:05
...
auch ich nutze Firebird.
Wenn man die Embedded Variante nutzen will muss man nur die entsprechenden Dateien mitliefern
und noch nicht mal was installieren
...
das ich hier auch Fürsprecher für firebird bin, können sich die meisten eh schon denken.
ergänzende infos: auch die netzwerkfähige Version firebird.exe kann ohne Installation
benutzt werden, braucht auf dem Server daher auch keine admin rechte oder sonstwas.
Einfach firebird.exe -a starten und schon läuft das im application modus, ob firewall
rules dann eine externe verbindung dann verhindern, steht auf einem anderen blatt.

Aber selbst mit installation aus dem zip file ist das mit einer Zeile mit einer batch
datei erledigt, ebenso uninstall. Und wenn ein Kunde zB gleichzeitig mehrere Firebird
Versionen schon einsetzt, kann man nicht nur diverse Instanzen der gleichen Version
installieren, sondern auch problemlos noch alle versionen von firebird 2.x bis 5.x
auf einem server mit unterschiedlichen tcp ports parallel laufen lassen, unter windows
auch mit der o.a. batch und einem parameter und angepasstem port in der firebird.conf

Das IBExpert eine auch kommerziell einsetzbare kostenlose personal edition hat kann
ich ja noch mal nebenbei erwähnen.

Bei der gruseligsten Installation, die wir mal vorgefunden hatten, gab es für verschiedene
Softwarelösungen aus der Versicherungsbranche 15 verschiedene Firebird parallel, die
jede das konzept hatten, wer zuletzt installiert, der hat gewonnen. Die mit uns zusammen
entwickelte Software nutze einen anderen port und einen anderen servicenamen und lief
immer ohne probleme sogar auf so einer Kiste.

Bezgl der Anforderungen im ersten Post: wir haben diverse Datenbanken auch mit
Tabellen mit mehr als einer Milliarde Datensätze im Einsatz, 500gb bis 5TB sind nicht
wirklich problematisch, auch wenn es da gute argumente gibt, das in extra datenbanken
aufzuteilen.

Bzgl einfache installation für Netzwerk: wenn dein installer einfach den inhalt aus
der firebird zip version mit vorbereiteter security*.fdb und angepasster firebird.conf
(DefaultServicePort anders als 3050) ausliefert,
brauchst du deinem installer nur noch erklären, das der die Kommandzeile

install_service.bat MeinFBServerName

aufruft. Dann siehst du einen Service mit diesem namen, der autostartet und sonst
brauchst du nix wissen oder machen.

Deine exe kann dann eine fbclient.dll (mit msv*.dll) im eigene pfad mit ausliefern und
schon ist es egal, ob auf dem Zielrechner auch 15 andere firebirds bereits installliert
sind.

Wenn Netzwerk eh nicht gebraucht wird, pack einfach den kram aus der zip datei in der
für dich passenden 32 oder 64 bit version mit in den installer und schon brauchst du
keinerlei extra setup für Datenbankfunktionen aus deiner delphi app, die dann mit
firebird, ibdac von devart.com oder anderen Komponenten den zugriff erledigt.
das ist dann embedded seit fb3.

Kosten sind für firebird dauerhaft 0 € egal wie oft du das brauchst oder für wen oder
unter welcher lizenz deine eigene Software steht. Es zwingt dich niemals irgendjemand
eine neue Version installieren zu müssen wie das mit mssql gerne mal passiert.

Wir hatten gerade vor kurzem noch eine Firebird 1.0 Datenbank von einem Kunden bekommen, die
zuletzt vor 23 Jahren ein createdatabase bekam. ist aber auch heute noch täglich im einsatz bei dem
(mittlerweile mit einem uralten windows virtualisiert, aber egal, es läuft schnell genug
für seine Zwecke).

Und wenn du dann wirklich neben der online doku nicht weiterkommst sind hier im forum
sicher 10-20 aktive user dabei, die damit arbeiten und auch noch schnell mal fragen
beantworten (wie ich), es sei denn es sind absolute DAU Fragen, die man mit google hätte auch
so beantworten können. Bei btrieve wird das ganz sicher schon einiges weniger an delphi Know
how geben in öffentlichen Foren und oft sind solche preiserhöhungen der letzte sargnagel
für kommerzielle datenbankserver (siehe Advantage Database Server), die dann nur noch von
Leuten benutzt werden, die davon aus welchen gründen auch immer nicht weg kommen.

Falls Replikation gebraucht wird, geht ja auch das mit externen tools oder seit fb4 internen
Funktionen in verschiedenen Qualitätsstufen, aber selbst für ein stündliches live backup
der Datenbanken ohne externes Tool muss sich niemand abmelden, das kann über gbak
oder deine app per komponente jederzeit laufen, während alle anwender ganz normal
weiter arbeiten.

Und alles was ich hier beschreibe geht auch mit embedded, technisch ist in allen
versionen auch immer alles was man per sql macht in der jeweiligen Versionsnummer
identisch machbar. Und fast immer sind spätere updates auf neue version
rückwärtskompatibel, d.h. deine sqls, die unter fb2.x liefen, sind fast immer
nach backup/restore auch mit fb5.x ausführbar, es sei denn du hast da unglückliche
Objektnamen benutzt, aber auch das kann man lösen.

Ich kenn in der Firebird Welt keinen Kunden, der sich ernsthaft mit Firebird
beschäftigt und offen ist für externen Support, der jemals gezwungen war, auf
irgendeine andere Plattform umzustellen.
Holger Klemt
www.ibexpert.com - IBExpert GmbH
Oldenburger Str 233 - 26203 Wardenburg - Germany
Firebird 5 Update und Know-how Workshop – 28.8.-29.08.2025 64546 Mörfelden - Walldorf

Geändert von IBExpert ( 7. Sep 2024 um 19:08 Uhr)
  Mit Zitat antworten Zitat
johndoe049

Registriert seit: 22. Okt 2006
174 Beiträge
 
#6

AW: Empfehlung für SQL-Datenbank

  Alt 7. Sep 2024, 21:10
Bei der Gelegenheit eine Frage zu Firebird und Datenbankverschlüsselung.

Bei IBExpert gibt es eine Verschlüsselungsmodul zu kaufen. Muss man das pro Kunden/Installation kaufen oder sind die Vertriebsrechte für Verwendung in eigener Software mit enthalten?
  Mit Zitat antworten Zitat
Benutzerbild von IBExpert
IBExpert

Registriert seit: 15. Mär 2005
695 Beiträge
 
FreePascal / Lazarus
 
#7

AW: Empfehlung für SQL-Datenbank

  Alt 8. Sep 2024, 06:26
https://www.ibexpert.net/ibe_de/pmwi....EncryptionOEM

"Unlimitierte Weitergabe des Moduls mit den Softwareprodukten des Lizenzinhabers ohne gesonderte Freischaltung.
Eine isolierte Weitervergabe ohne Softwareprodukte des Lizenzinhabers oder als Freeware ist nicht erlaubt."

funktioniert auch mit fb5, müssen wir da mal anpassen
Holger Klemt
www.ibexpert.com - IBExpert GmbH
Oldenburger Str 233 - 26203 Wardenburg - Germany
Firebird 5 Update und Know-how Workshop – 28.8.-29.08.2025 64546 Mörfelden - Walldorf
  Mit Zitat antworten Zitat
MichaelT

Registriert seit: 14. Sep 2005
Ort: 4020 Linz
558 Beiträge
 
Delphi 10.3 Rio
 
#8

AW: Empfehlung für SQL-Datenbank

  Alt 8. Sep 2024, 10:59
Ein weiser Mann spricht weise Worte. Hast schon recht.

Der BTRIEVE ist ein guter alter Record Server und das war in den 1980ern und 1990ern ein Vorteil, da man den Record einfach in ein Objekt hat reinkopiert und über Properties die Ausgabe in Richtung Delphi IDE hat einfach gestalten können. Da braucht es allein ein wenig ein Datenbank Objekt und einen Schema Generator und man bekommt den Datenbestand 1:1 konsistent in die Applikation rein gemapped. Das Zeug war sauschnell, damals bis zu 50 mit einer Warenwirtschaft, KORE und FIBU den lieben langen Tag (intensiv inkl Reporting) arbeitenden Usern und kotzte in der Praxis kaum ab, ähnlich 4th Dimension.

Firebird ist in der Praxis die 'neue' teamfähige Personal Oracle, so wie früher mit der Ampel zu starten, plus Netzwerk. Darüber hinaus geht praktisch alles mittlerweile und in der Praxis komfortabler.

Ich habe bitte einen RAC mit einer Tabelle, sorry zwei,

create table neighbors(ID integer, CALLEM varchar2(255), FK_DOSOMETHING_ID integer) mit PK usw...

Dafür aber 6 Tools at Hand inkl. Plyxon (unter Linux), Oracle SQL Developer, SQL Detective, Clear SQL (für eine procedure ADAROCKS_HOWDY(pCALLEM varchar2 .... - schwer qualitätsgesichert, Clear DB für die Schemadokumentation, PL/SQL Developer usw...

Darin sind 4 Datensätze für Hippy, Hoppy, Julian the Wise OWL und ein Satz mit CALLEM für gängige Sonderzeichen.

Ich habe lange gesucht nach einer Ablöse und am Ende blieb ein wenig unerwartet mittlerweile der Firebird.

Dort gibt es die Häschen und die Eule mit Bildern - progress on steroids usw.. Scherzerl.

Beim Firebird war der Drive die letzten Jahre gewaltig.

Mittlerweile ist Firebird die würdige Nachfolge für solche Szenarien.
Elevate DB hat auch einen Lack und
NexusDB und
Interbase (jetzt wertfrei, wenn einer unbedingt glaubt).

Elevate DB ist einfach zu administrieren und hat eine brauchbare Verschlüsselung usw. NexusDB ist runder aber kann fast zu viel an dem Eck.

Nimmt man noch PHP dazu, dann wird es mühselig. Dann rücken wieder MySQL, MariaDB und Postgres in den Fokus, mal von NoSQL DBs abgesehen.

Ich würde mir auf jeden Fall die Community rund um PHP PDO module (Treiber), .net und Java Connectoren ansehen und ODBC Treiber.

Mimer, ist aber bestimmt nicht billig, wäre die Liga SQL Server and Beyond (mittlerweile vermutlich auch nicht mehr) und praktisch SQL Anywhere on Steroids. Wohl aber hat das Self Tuning schon vor 20 Jahren an sich klaglos, im Dauerbetrieb getestet, funktioniert.

Wenn man XBASE und nicht BTRIEVE migriert gibt es zumindest Alternativen bei denen der Datenbestand übernommen werden kann.

-

Vorteil ist heutzutage, dass die Kunden für die Verschlüsselung werden gerupft und nicht für 'neue Datenbankfeature' und deren Verbesserung. Seitdem funktioniert alles halbwegs zeitnah und klaglos. Apollo bspw.

Wer über Delphi klagt, dem sei einmal Harbour empfohlen , ist zwar geil, aber ernüchternd (Clipper Compiler auf GCC).

-

Schemaänderung im Betrieb auf großen Datenbeständen bist bei Oracle und diesbezüglich war diese Datenbank schon immer segensreich und auch was Networking angeht.

-

Aber als Ablöse für Szenarien, welche sich jetzt nicht auf die eine Tabelle beschränken, ich fahre den Oracle Cluster allein zur Gaudi hoch, deswegen bleib es bei einer Tabelle oder zwei, ist Firebird am Ende der verbliebene Kandidat. Ich kenne einige die mit dem Firebird sich schon mit 1.0 rumplagten, aber die haben seitdem ganz gut immer einen positiv Zugewinn erfahren und waren am Ende immer zufrieden und wurden immer zufriedener (Linux). Der Firebird kann was es braucht.

Mein Präferenz ist so lean wie nötig und so ausbaufähig wie möglich. In Österreich haben in Ermangelung anderer Alternativen Unternehmen einfach Oracle genommen, gut lief stabil, aber da die Oracle alle nahmen (der SQL Server hieß vermutlich noch Sybase also vor 6). Hernach waren die Ablöseorgien. Mit der Zeit kamen die Unternehmen drauf, dass Oracle für 'wahre Männer' ist und der Charme der DB wurde gekonnt versteckt, aber 'Smells like the IBM Host' war eben zur Zeit des Grunges schon nicht der Teen Spirit, sondern eine Notwendigkeit. Auch wenn ich sonst über eine Oracle nichts kommen lasse. Aber die Version auf 19 raufzufahren, damit mal einmal in der DB am CLI JSON Value Repräsentationen von Werten aus Tabellen bekommt, das war vor geraumer Zeit schon ernüchternd.

Die Nische in Österreich war Oracle auf Windows NT 4 mit 7 und die Trials mit dem Nag Screen gingen weg wie die warmen Semmeln oder die anderen CDs. Durchstarten war in der Regel selten der Fall.

--

Der Firebird war schon zu Zeiten 3 Alpha, bis auf ein paar Troubles mit rekursiven Abfragen (macht eine Elevate DB nicht) und dabei die Systemgrenzen zu sprengen, von einem Freund (Waschbär) von mir die Option schlechthin. 'Weg von Oracle' für überschaubare Szenarien war vor ca. 15 Jahren angesagt.

Mit embedded Szenarien usw. nimmt sich die Sache wieder anders aus und die Lizenzen pro Arbeitsplatz, die brauchen Hersteller, liegt auf der Hand, aber tut sich keiner an. Die relationalen Datenbanken und SQL waren nicht beleibt, da SQL so super war, sondern da Abteilung für Änderungen an den Anwendungen immer fette Beträge aus ihrem Budgets mussten abdrücken. Die Daten wurden reingeklopft in der DB2 auf Files oder direkt am Fielsystem von der IT Organisation verwaltet und raus kam nichts ohne Löhnemann.

Die bekamen auf dem Wege Zugriff auf 'ihre' Daten, sonst war außer mit dem Query Management Facility nicht viel (QMF).


Moin...

@TE

Am Ende des Threads wirst du nicht schlauer sein...weil jeder seine Vorlieben herausstellt.
  Mit Zitat antworten Zitat
Benutzerbild von TigerLilly
TigerLilly

Registriert seit: 24. Mai 2017
Ort: Wien, Österreich
1.241 Beiträge
 
Delphi 12 Athens
 
#9

AW: Empfehlung für SQL-Datenbank

  Alt 9. Sep 2024, 09:35
Ich würde gern MSSQL Express ins Spiel bringen.
https://www.microsoft.com/de-de/down...aspx?id=104781

- Installiert in 99% der Fälle problemlos
- Verwaltungstool inkludiert
- hoch performant + skalierbar
- als Einzelplatz und als Server einsetzbar
- kostet nichts

Wir nutzen das seit vielen Jahren für unterschiedlichste Zielgruppen und hatten noch nie das Gefühl wechseln zu müssen.
  Mit Zitat antworten Zitat
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.643 Beiträge
 
#10

AW: Empfehlung für SQL-Datenbank

  Alt 9. Sep 2024, 10:37
Also der aktuelle "Industriestandard" ist meines erachtens PostgreSQL.

MySQL / MariaDB sehe ich schon seit vielen Jahren nicht mehr produktiv im Einsatz - bei keinem unserer Kunden. Der Grund ist, das MariaDB eher "leichtgewichtiger" ist. Eigentlich gut, aber bei größeren Datenbanken macht Maria dadurch dann irgendwann die Grätsche und bricht komplett ein. Also kleine DB: MariaDB, größere DB's: Was "richtiges".
Oracle ist Lizenztechnisch und handhabungsmäßig ne Vollkatastrophe.
Microsoft SQL Server ist gut und benutze ich auch gerne, aber die Express-Edition ist zu eingeschränkt und bei der richtigen Variante hast Du wieder das Lizenzkostenproblem. Zudem gibt es hier für ARM-Hardware (noch?) keine gescheiten Images.
Firebird ist halt eher eine Nischen-DB, die nahezu ausschließlich im Delphi-Umfeld genutzt wird.

Das ist per se natürlich nicht schlecht, aber daraus ergibt sich, dass die Community die Dir hier helfen kann leider sehr überschaubar ist. Postgres kennt da draussen nahezu jeder, der aktuell irgendwas mit hochperformanten Datenbanken machen muss. Dementsprechend gibt's dort für alle erdenklichen Situationen schon Artikel und fertige Lösungen.

Dazu kommt, das PostgreSQL auch neben dem primären Relationalen Modell auch (ggf. mit extensions) Support für Document-Store (no-sql), Graph-DB, Spatial DB's (Geo-Daten / Koordinaten), und auch Vektor-Storage hat (und das wird aktuell immer wichtiger für performante semantische Suchen).

Ich würde an Deiner Stelle einfach mal von allem was in die nähere Auswahl kommt eine DB in einem Docker Container hochfahren, deine Daten da reinschieben, und dann gucken wie sich das jeweils anfühlt und wie das performt.
Sebastian Gingter
Phoenix - 不死鳥, Microsoft MVP, Rettungshundeführer
Über mich: Sebastian Gingter @ Thinktecture Mein Blog: https://gingter.org
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

 
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:45 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz