Mac Datenbanken

[mauerritze]

Hi,

bin neu hier also entschuldigt bitte falls di Frager schon einmal beantwortet wurde.


Ich arbeite sehr sehr viel mit SAP und muss da zu mit vielen Excel Tabellen arbeiten.
Im Moment füge ich z.B 8 Tabellen über MS Access auf einer Citrix Farm zusammen um auf eine Abfrage ect.. zu kommen.

Gibt es eine andere Möglichkeit Datenbanken, Abfragen usw. LOKAL auf dem Mac zu erstellen?
Mit xlsx Importe und Exporte...
ParallelDesktop mag ich nicht verwenden da ich dann wieder auf einer Windows ebene arbeite.

Lieben danke für eure Hilfe
MFG
mauerritze

 

[Bountyhunter]

Alternativen gibt es viele !
Willst Du die Datenbanken ausschließlich LOKAL haben oder sollen die auch anderen zur Verfügung stehen ?

 

[mauerritze]

Alternativen gibt es viele !
Willst Du die Datenbanken ausschließlich LOKAL haben oder sollen die auch anderen zur Verfügung stehen ?

Hi,

Nee die sollen nur Lokal sein mehr nicht

 

[Bountyhunter]

Warum bleibst Du dann nicht bei Excel ?
Bei allem anderen musst Du Abstriche beim Datenaustasch zwischen Excel und "was auch immer Programm" machen und die Formeln gehen bei solchen Sachen meist verloren.
Habe auch lange mit Alternativen rumgefummelt - letztendlich bin ich bei Excel geblieben und wenn ich Tabellen austauschen muss um sie mit anderen bearbeiten zu können, dann nehme ich "Google Tabellen".
Damit klappt das gemeinsame Arbeiten wunderbar und es kommt sehr nahe an Excel ran.

 

[Wuchtbrumme]

nur mal terminologisch: Excel ist KEINE Datenbank. Brrr.

Geht es um richtige Datenbanken würde sich mySQL anbieten (gibt es auch als Paket zum Runterladen und Gleich-Benutzen). Strukturell ist das aber zu Excel ein Unterschied wie Tag und Nacht. Die Vorteile einer Datenbank muss man erst mal erkennen, hat man das getan, wird einem klar, wofür man Excel wirklich benutzen möchte.

Richtige Datenbanken für den Mac gibt es gar nicht so sehr viele; ich würde sagen, das einzige Ernsthafte, was ich kenne (und auch nur vom Namen her) wäre FileMaker - weil es das schon ewig gibt und viel drauf entwickelt wird.

Aber wenn da schon SAP steht, ist mir einiges klar.

 

[daapfel]

Schau dir mal Ninox (macOS/iOS) an. Da lassen sich Daten in Excel exportieren. Import kann ich aus dem Stehgreif nicht sagen.

 

[Scotch]

FileMaker ist auch die einzige Desktop-DB die ich für den Mac kenne. Die ist auch recht leistungsfähig - aber die Frage, wozu man heute noch Desktop-DB braucht stellt sich schon. Macht eigentlich nur Sinn, wenn man da irgendeine App 'drauf baut (dafür wird ja auch FM überwiegend eingesetzt).

Ansonsten ist der sinnvolle Weg heute eine SQL-DB mit passendem Frontend. Ich benutze z.B. MariaDB und wenn ich nicht eh' programmatisch damit arbeite Valentina Studio als Frontend, also um mal eben eine Abfrage zu erzeugen usw. Eine lokale Alternative wäre SQlite mit einem passendem Frontend (ich benutze dafür Xcode, wenn ich mal was mit SQlite mache ).

Grundsätzlich klingt das OP aber tatsächlich eher nach einem Job für VBA als für eine DB...

 

[FM-Spezi]

Es gab in der Vergangenheit viele Ansätze Datenbanken auf dem Mac zu implementieren (u.A. Forth Dimension u.a.). Durchgesetzt haben sich über die Jahre aber nur mySQL und FileMaker.
Während man für mySQL aber immer noch ein Frontend entwickeln muss, um damit einigermaßen userfreundlich umgehen zu können, ist FileMaker Datenbank und Frontend zugleich. Beiden Datenbanken ist gemeinsam, dass sie systemübergreifend, also sowohl unter Windows als auch auf Mac genutzt werden können.
Der Einstieg in FileMaker ist für Laien einfach - manchmal zu einfach, weil man einfach loslegen kann ohne große Grundkenntnisse in relationalen Datenbanken zu haben. Das rächt sich, spätestens wenn man zusätzliche Funktionen einbauen oder die Anwendung hochskalierten möchte. Die unbedingt notwendigen Grundkenntnisse, die ein Nutzer von SQL Datenbanken zwangsläufig mitbringt sind da schon sehr von Nutzen, auch wenn sich derjenige mit dem gänzlich anderen Look and Feel der FM-DB zunächst schwer tun wird.
Letztendlich sind die mit FileMaker erzeugten Auswerte-Layouts aber nichts Anderes als die von SQL-Datenbanken bekannten "stored proceedures" - nur dass sie zunächst einmal ganz ohne SQL funktionieren.
Ich würde für den vorliegenden Fall schon deshalb FileMaker empfehlen, weil der Import von Excel-Tabellen ein Kinderspiel ist. Ferner gibt es eine ODBC-Schnittstelle mit der auf SQL-Datenbanken zugegriffen werden kann (z.Zt. unterstützt: Oracle und MS SQL-Server) - da wird Filemaker nicht nur zum Frontend sondern kann die Daten mit den lokal gehaltenen kombinieren. Da SAP meines Wissens auf einem Oracle Datenbankkernel aufsetzt, ein weitere Grund, es mit Filemaker zu versuchen.

 

[MacAlzenau]

Je nach dem Umfang der Datenbank und wie sie genutzt werden soll, kann man sich auch mal die DB-Module von OpenOffice und LibreOffice anschauen.
Vermutlich nicht so "mächtig" wie FileMaker und SQL-Datenbanken, aber möglicherweise völlig ausreichend.

 

[Scotch]

Das die Frage über drei Jahre alt ist, ist euch aber aufgefallen?

 

[radioenrique]

Das die Frage über drei Jahre alt ist, ist euch aber aufgefallen?

Danke, ist mir nicht aufgefallen. Ich bin z. Zt. am Überlegen, statt einer sehr umfangreichen Numbers-Tabelle (über 200MB, enthält sehr viele Bilder) auf eine Datenbank umzusteigen. Daher ist dieser Thread für mich nützlich, auch wenn er schon älter ist.

 

[Scotch]

Dann solltest du überlegen, ob für so eine Anwendung nicht ggf. eine einschlägige Bildverwaltung, z.B. im simpelsten Fall die in Fotos integrierte DB, eine sinnvollere (und einfachere) Lösung ist.

 

[radioenrique]

Dann solltest du überlegen, ob für so eine Anwendung nicht ggf. eine einschlägige Bildverwaltung, z.B. im simpelsten Fall die in Fotos integrierte DB, eine sinnvollere (und einfachere) Lösung ist.

Ich bin ein „AFOL“, ein „Adult Fan Of LEGO“ und besitze eine umfangreiche LEGO-Sammlung. Um einen Überblick über die Vielzahl meiner Steine zu haben, habe ich vor vielen Jahren diese Tabelle angelegt und sie ist mit der Sammlung mitgewachsen.
Laut LEGO gibt es z. Zt. etwa 3900 unterschiedliche LEGO-Elemente (=Formen) in 67 Farben. (Nicht jedes Element ist in jeder Farbe verfügbar)
Ich besitze ca. 80000 Steine. Die Numbers-Tabelle baut sich im Wesentlichen in Elemente ( Reihen) ind Farben (Spalten) auf. An der Schnittstelle ist ein Bild des betreffenden Elementes in der jeweiligen Farbe und Stückzahl.
So habe ich pro Reihe in der linkesten Spalte die Bezeichnung des LEGO-Elementes und nach rechts fortfahrend die Stückzahl nach Farben. Sieht dann so aus. (Screenshot vom iPhone SE 2016, ist nur ein kleiner Ausschnitt der Tabelle)

Ich denke, die Foto-App oder einer anderen Fotoverwaltung ist nicht das Richtige. Das Problem ist, daß die Tabelle in der iCloud liegt und immer länger zum Laden braucht. Daher, denke ich, wäre eine DB die bessere Lösung.
Aber welche? Ich habe mit DBs überhaupt keine Erfahrung.
Prosit Neujahr!

 

[wavelow]

FileMaker ist auch die einzige Desktop-DB die ich für den Mac kenne.

Ninox ist ebenfalls eine native Datenbank Mac App. Meist wird es aber in Verbindung mit der iCloud bzw. externen Ninox Server genutzt. Geht aber auch nur lokal.

Ich bin z. Zt. am Überlegen, statt einer sehr umfangreichen Numbers-Tabelle (über 200MB, enthält sehr viele Bilder) auf eine Datenbank umzusteigen. Daher ist dieser Thread für mich nützlich, auch wenn er schon älter ist.

Ninox kann das. Dort kannst Du Bilder, PDF usw. in die Datenbank mit aufnehmen die auch ein sehr grosses Volumen annehmen kann. Ich selber nutze Ninox schon Jahre professionell und habe mittlerweile auch schon große Unternehmen davon überzeugen können es zu nutzen. Extrem flexibel und zuverlässig das Ganze. Und durch die Low-Code Sache kann damit jeder Datenbanken bauen.

 

[Scotch]

Ich denke, die Foto-App oder einer anderen Fotoverwaltung ist nicht das Richtige.

Da stimme ich zu

 

[MacAlzenau]

Warum muß die Tabelle denn in der Cloud liegen?

 

[radioenrique]

Warum muß die Tabelle denn in der Cloud liegen?

Weil ich gelegentlich auch mit dem iPad darauf zugreife.
Ein Sync zw. macOS, iOS und iPadOS ist notwendig.