Newbie Frage zur Datenbankauswahl

[ChrisE]

Hallo,

wir brauchen in naher Zukunft eine einfach Datenbanklösung. Ich habe schon versucht mich in verschiedene Bereich ein zu lesen, doch irgendwie überflutten mich die Informationen. Daher wollte ich hier mal die Leute befragen, die sich damit wirklich auskennen. :duck:

Die Anforderungen sind folgende:

• Zugriff von Single-User-Installationen, Mini-Netzen (3-5 Clients) und größeren Netzen bis zu 50 Clients
• Hauptsächlich gibt es lesende Zugriffe, schreiben kann jedoch in "Stoßzeiten" durchaus von allen Clients aus geschehen (quasi-parallel)
• Einfache Installation der Datenbank für Single-User und Mini-Netze - am besten nur durch kopieren von Dateien (ohne Services etc.)
• Simple Umstellung auf größere Netze, die dann wahrscheinlich auf einen Server / Service zugreifen
• Single-User und Mini-Netze am besten ohne zusätzliche Lizenzkosten
• Einsatz in Closed-Source Entwicklung erlaubt

Ich habe schon ein bisschen was mit SQLite gemacht aber die Anforderung "Multi-User" lässt diesen Weg nicht mehr zu. Des weiteren bin ich auf TurboDB gestoßen, wobei ich nicht sicher bin ob die all die Anforderungen erfüllen (größere Netze mit bis zu 50 Clients gleichzeitig -> Anfrage diesbezüglich läuft aber). Dann habe ich auch noch aus den Forum heraus gelesen, dass Firebird eine gute Lösung wäre, nur überblicke ich hier ganz ehrlich gesagt nicht, ob das nicht schon zu "groß" wäre für die Anforderungen und wie die Umstellung zwischen den einzelnen Modi (Emb vs. Server) läuft etc. Aber das würde ich dann in einem neuen Thread erfragen. Immer nur eine Frage pro Thread :-)

Danke auf jeden Fall für Eure Unterstützung.

Chris

[scrat1979]

Hallo!!

Ich würde mich ganz klar für FireBird entscheiden. Die Skalierung von Single-User zu Multiuser (bzw. lokal zu server) ist wirklich ein Klacks (Wenige Einstellungen in der entsprechenden Komponente in Delphi). Es läuft sehr stabil und schnell. Nicht zuletzt eignet es sich aufgrund der Lizenzbedingungen ebenfalls sehr gut. Es gibt haufenweise gute Admin-Tools (GUIs) wie z.B. Firebird Maestro oder SQL Manger for Firebird. Damit lassen sich die Datenbanken einfach und übersichtlich pflegen (inkl. Zugriffsrechte). Als Zugriffskomponenten verwendet ich IBDAC, es gibt auch andere - von einigen hier im Forum favorisierte - Alternativen (Forensuche).

Auch als Datenbank-Newbie wird es Dir möglich sein, mit Hilfe der Schnellanleitung von Firebird innerhalb von 20 Minuten (inkl. Firebird-Installation) eine Anwendung zu schreiben um z.B. Daten in einem DBGrid anzuzeigen. Es ist wirklich kein Hexenwerk. Wenn du Hilfe brauchst sind wir ja immer für Dich da :)

Von den o.g. GUIs gibt es Demoversionen, bei IBDAC müsstest du mal schauen.

Grüße,

Michael

[mkinzler]

FireBird ( ab 2.5) wäre auch mein Vorschlag gewesen.
Bei SingleUser: embedded
3-5: embedded ( bei FB2.5) aber besser Server ( Service oder Programm)
> 50: Server

Für FireBird fallen keine Lizenzkosten an. Kommerzielle Nutzung erlaubt.
Die Umstellung von embedded auf Server funktioniert einfach per Connectionstring ( bei embedded Serverteil leer)

[RWarnecke]

Vielleicht ist dieser Beitrag aus dem Delphi-Forum noch etwas für Dich.

[blackfin]

Meine Empfehlung ist auch ganz klar der Firebird (>= 2.5).
Die Datenbank ist extrem stabil (sogar, wenn man teilweise richtige "Schweinereien" mit ihr macht) und ziemlich fix.

Ich arbeite oft damit, nehme gerne den embedded Server und nutze die Zeos-Komponenten dafür.
Bisher hatte ich damit bisher null Probleme, im Gegensatz zu manch anderen Datenbanken.....

Ausserdem ist eine Applikation damit sehr schnell an den Kunden gebracht, ohne COM-Server Hölle oder dergleichen.
(btw: kennt jemand zufällig die Valentina Datenbank? DAS ist die Hölle!)

[ChrisE]

Hallo,

Zitat:

Zitat von scrat1979

Als Zugriffskomponenten verwendet ich IBDAC, es gibt auch andere - von einigen hier im Forum favorisierte - Alternativen (Forensuche).

Würde sich hier auch UniDAC anbieten, da ja so die DB-Architektur egal wäre?

Zitat:

Zitat von mkinzler

FireBird ( ab 2.5) wäre auch mein Vorschlag gewesen.

Hab ich das richtig gesehen, dass es hier bisher nur einen RC gibt?

Zitat:

Zitat von mkinzler

Für FireBird fallen keine Lizenzkosten an. Kommerzielle Nutzung erlaubt.

D.h. ich kann den Server von der Seite dort runter laden und bei jedem Kunden installieren, ohne Lizenzprobleme bzw. die Embedded-Version immer mit ausliefern und den Server nur bei Usern > 3 Plätzen?

Zitat:

Zitat von mkinzler

Die Umstellung von embedded auf Server funktioniert einfach per Connectionstring (bei embedded Serverteil leer)

D.h. beim Coden selber macht man sich zunächst keine Gedanken darum, ob es später Multi-User oder Single-User wird. Man Programmiert z.B. alles so als ob es sich immer auf einen Server verbindet. Es kann dann später nur per "Konfig-Datei" entschieden werden. Worauf verbunden wird ist aber für die Anwendung erst mal egal?


@RWarnecke: Danke, lese ich mir mal durch

Zitat:

Zitat von blackfin

Ich arbeite oft damit, nehme gerne den embedded Server und nutze die Zeos-Komponenten dafür.
...
Außerdem ist eine Applikation damit sehr schnell an den Kunden gebracht, ohne COM-Server Hölle oder dergleichen.

D.h. das ist wohl wirklich das was ich mir vorstelle. Ein paar Dateien auf den Client kopieren und anpassen (.conf) und schon kann's losgehen. Welche Gründe sprechen bei Dir für Zeos?

Danke an alle,

Chris

[Bernhard Geyer]

Zitat:

Zitat von ChrisE

Zitat:

Zitat von scrat1979

Als Zugriffskomponenten verwendet ich IBDAC, es gibt auch andere - von einigen hier im Forum favorisierte - Alternativen (Forensuche).

Würde sich hier auch UniDAC anbieten, da ja so die DB-Architektur egal wäre?

Ist es nicht. Der Aufwand eine anderes DBMS zu unterstützen wird nur bei solchen Zugriffskomponenen geringen. Wenn dann brauchst du ein Bridge-Pattern oder Objektrelationales Framework (bei Java Hibernate) welche wirklich auch die SQL-Unterschiede kapseln.

[mkinzler]

Zitat:

Würde sich hier auch UniDAC anbieten, da ja so die DB-Architektur egal wäre?

Ja, UniDAC sollte das selbe leisten wie IBDAC ( kenne aber nur 2.)

Zitat:

Hab ich das richtig gesehen, dass es hier bisher nur einen RC gibt?

Ja. Dieser ist aber sehr stabil. Ich gehe von einer Veröfentlichung in der nächsten Zeit aus. Alternativ halt die Vorgängerversion, bei dieser ist die embedded aber nicht multiuserfähig ( hier würde ich aber eh auf den Server setzen)

Zitat:

D.h. beim Coden selber macht man sich zunächst keine Gedanken darum, ob es später Multi-User oder Single-User wird. Man Programmiert z.B. alles so als ob es sich immer auf einen Server verbindet. Es kann dann später nur per "Konfig-Datei" entschieden werden. Worauf verbunden wird ist aber für die Anwendung erst mal egal?

Ja, ist völlig egal. Die selbe Anwendung kann sowohl auf lokale/embedded wie auf eine Server zugreifen

Zitat:

Welche Gründe sprechen bei Dir für Zeos?

Höchstens der Preis (kostenlos). Zeos hat das Problem, dass keine harten Commits unterstützt werden. Was bei Multiuserzugriff ein echtes Problem darstellt.

[RWarnecke]

Zitat:

Zitat von ChrisE

Zitat:

Zitat von scrat1979

Als Zugriffskomponenten verwendet ich IBDAC, es gibt auch andere - von einigen hier im Forum favorisierte - Alternativen (Forensuche).

Würde sich hier auch UniDAC anbieten, da ja so die DB-Architektur egal wäre?

Ich selber habe die UniDAC Komponenten bei einem Projekt eingesetzt. Die Dinger sind der Wahnsinn. Ich habe keinerlei Probleme gehabt.

Zitat:

Zitat von ChrisE

Zitat:

Zitat von mkinzler

FireBird ( ab 2.5) wäre auch mein Vorschlag gewesen.

Hab ich das richtig gesehen, dass es hier bisher nur einen RC gibt?

Die letzte stabile Version ist 2.1.3. Ich nehme mal an, dass die Version 2.5 vorgeschlagen wurde, wegen den kleinen Netzen. Denn bei der Embedded Version 2.5 kannst Du mit mehreren Usern auf die Datenbank zugreifen, nicht wie bei der Version 2.1.3. Da geht es nur mit einer Person.

Zitat:

Zitat von ChrisE

Zitat:

Zitat von mkinzler

Für FireBird fallen keine Lizenzkosten an. Kommerzielle Nutzung erlaubt.

D.h. ich kann den Server von der Seite dort runter laden und bei jedem Kunden installieren, ohne Lizenzprobleme bzw. die Embedded-Version immer mit ausliefern und den Server nur bei Usern > 3 Plätzen?

Ja, kannst Du. Siehe mein Code-Orakel. Das Programm hat die Firebird Version 2.1.3 Embedded.

[scrat1979]

Zitat:

Zitat von scrat1979

Als Zugriffskomponenten verwendet ich IBDAC, es gibt auch andere - von einigen hier im Forum favorisierte - Alternativen (Forensuche).

Würde sich hier auch UniDAC anbieten, da ja so die DB-Architektur egal wäre?

Jein. Wenn Du Befehle benutzt, welche in den entsprechenden DBMS IDENTISCH sind, dann ja. Dann müsstest du Dich allerdings für die Pro-Version entscheiden, da erst hier die entsprechenden Service-Provider für die einzelnen Datenbanksysteme mit ausgeliefert werden. Wie schon gesagt werden von UniDAC allerdings keine DatenbanksystemSPEZIFISCHEN Features unterstützt (z.B. Komponente zur Rechteverwaltung in Firebird)

Zitat:

Zitat von mkinzler

FireBird ( ab 2.5) wäre auch mein Vorschlag gewesen.

Hab ich das richtig gesehen, dass es hier bisher nur einen RC gibt?

Macht doch nichts, die Version 2.1 ist doch in der FINAL vorhanden und sehr gut :)

Zitat:

Zitat von mkinzler

Für FireBird fallen keine Lizenzkosten an. Kommerzielle Nutzung erlaubt.

D.h. ich kann den Server von der Seite dort runter laden und bei jedem Kunden installieren, ohne Lizenzprobleme bzw. die Embedded-Version immer mit ausliefern und den Server nur bei Usern > 3 Plätzen?

Ja! Die Skalierung macht keinerlei Probleme. Allerdings könnte es sein, dass Du bereits bei mehr als 1 Platz die Server-Version nehmen musst (solltest), was aber vom
Aufwand her auch nicht mehr Arbeit ist (einmal den Server installiert und bei den clienten eben Dein Programm mit der entsprechenden Firebird-Client-DLL installieren - Fertig!). Selbst ich war verwundert wie einfach das funktioniert :) Die Embedded-Version ist meines Wissens nur für Ein-Platz-Systeme (z.B. Entwicklungs-Rechner) geeignet.

Auch die (kostenlose!) komerzielle Verwendung ist ausdrücklich gestattet, Du wirst keinerlei Lizenzprobleme bekommen.

Zitat:

Zitat von mkinzler

Die Umstellung von embedded auf Server funktioniert einfach per Connectionstring (bei embedded Serverteil leer)

D.h. beim Coden selber macht man sich zunächst keine Gedanken darum, ob es später Multi-User oder Single-User wird. Man Programmiert z.B. alles so als ob es sich immer auf einen Server verbindet. Es kann dann später nur per "Konfig-Datei" entschieden werden. Worauf verbunden wird ist aber für die Anwendung erst mal egal?

IMHO nicht per Config-Datei sondern über den connection-String bzw. über die Einstellungen in der entsprechenden Komponente (wenige Mausklicks und Tastatureingaben)


SCRaT

[blackfin]

Zitat:

Welche Gründe sprechen bei Dir für Zeos?

Mhm, soll ich ehrlich sein? Ich kenne IBDAC nicht :-D
...und bisher war ZEOS für mich ausreichend.

Zitat:

Zeos hat das Problem, dass keine harten Commits unterstützt werden. Was bei Multiuserzugriff ein echtes Problem darstellt.

Wenn man die Datenbank kurz schliesst und wieder öffnet, dann macht auch ZEOS einen harten commit.
Da bietet es sich dann halt an, ggf. einen Connection Pool für den Multiuser-Zugriff und den Threads zu verwenden.
Das ging bisher eigentlich ohne Probleme.... :roll:

[mkinzler]

Zitat:

IMHO nicht per Config-Datei sondern über den connection-String bzw. über die Einstellungen in der entsprechenden Komponente (wenige Mausklicks und Tastatureingaben)

Und diesen liest das Programm dann aus einer Ini/Konfig/XML/Registry :zwinker:

[RWarnecke]

Zitat:

Zitat von scrat1979

IMHO nicht per Config-Datei sondern über den connection-String bzw. über die Einstellungen in der entsprechenden Komponente (wenige Mausklicks und Tastatureingaben)

Das kann man aber auch ruhig über eine Config datei machen. So löse ich es auch im Code-Orakel.

[scrat1979]

Zitat:

Zitat von RWarnecke

Zitat:

Zitat von scrat1979

IMHO nicht per Config-Datei sondern über den connection-String bzw. über die Einstellungen in der entsprechenden Komponente (wenige Mausklicks und Tastatureingaben)

Das kann man aber auch ruhig über eine Config datei machen. So löse ich es auch im Code-Orakel.

OHNE die Einstellungen in der Zugriffskomponente zu verändern? Ok, das wusste ich nicht. Wie dem auch sei, trotzdem wenige Klicks :)

[mkinzler]

Zitat:

Zitat:
Zeos hat das Problem, dass keine harten Commits unterstützt werden. Was bei Multiuserzugriff ein echtes Problem darstellt.

Wenn man die Datenbank kurz schliesst und wieder öffnet, dann macht auch ZEOS einen harten commit.
Da bietet es sich dann halt an, ggf. einen Connection Pool für den Multiuser-Zugriff und den Threads zu verwenden.
Das ging bisher eigentlich ohne Probleme.... Rolling Eyes

Das ist aber nicht gerade performant. Zudem bietet dir spezielle Zugriffskomponenten viele andere Features und Vorteile. IBDAC ist im Vergleich zu Zeos auch um eniges schneller.

[mkinzler]

Zitat:

Zitat von scrat1979

Zitat:

Zitat von RWarnecke

Zitat:

Zitat von scrat1979

IMHO nicht per Config-Datei sondern über den connection-String bzw. über die Einstellungen in der entsprechenden Komponente (wenige Mausklicks und Tastatureingaben)

Das kann man aber auch ruhig über eine Config datei machen. So löse ich es auch im Code-Orakel.

OHNE die Einstellungen in der Zugriffskomponente zu verändern? Ok, das wusste ich nicht. Wie dem auch sei, trotzdem wenige Klicks :)

Das Programm liest die Ini und setzt die Eigenschaften dann am Programmstart. Es ist imho wenig sinnvoll diese fest im OI zu setzen.

[blackfin]

Ich habe ja auch nur gesagt, dass es für mich bisher ausgereicht hat... :cry:

[mkinzler]

In seinem Fall sollte sich der Kauf von speziellen kommerziellen Komponenten aber lohnen

[scrat1979]

Zitat:

Zitat von mkinzler

Zitat:

Zitat von scrat1979

Zitat:

Zitat von RWarnecke

Zitat:

Zitat von scrat1979

IMHO nicht per Config-Datei sondern über den connection-String bzw. über die Einstellungen in der entsprechenden Komponente (wenige Mausklicks und Tastatureingaben)

Das kann man aber auch ruhig über eine Config datei machen. So löse ich es auch im Code-Orakel.

OHNE die Einstellungen in der Zugriffskomponente zu verändern? Ok, das wusste ich nicht. Wie dem auch sei, trotzdem wenige Klicks :)

Das Programm liest die Ini und setzt die Eigenschaften dann am Programmstart. Es ist imho wenig sinnvoll diese fest im OI zu setzen.

auch wenn es langsam OT wird, Du meinst aber eine "Programminterne" INI-Datei und nicht, dass die Komponenten von Haus aus eine INI-Datei im Programmverzeichnis suchen
und sich mit den entsprechenden Eigenschaften verbinden. Da bin ich natürlich Deiner Meinung, dass man das selbst über eine INI-Datei o.ä. realisieren und nicht hardcoden sollte. :cheers:

[mkinzler]

So hat er es wohl auch gemeint ( er hat es ja auf sein Programm bezogen). Eine Ini der Komponenten wäre auch nicht sinvoll, da ja dann nur eine Verbindung möglich wäre ( bei eigener Ini könnte man ja mehrere alternative Pfade und auch parallele Zugriffe auf mehrere Datenbanken/Bestände ermöglichen

[ChrisE]

Zitat:

Zitat von mkinzler

In seinem Fall sollte sich der Kauf von speziellen kommerziellen Komponenten aber lohnen

Also z.B. ZEOS oder IBDAC/UniDAC?

Zitat:

Zitat von mkinzler

So hat er es wohl auch gemeint ( er hat es ja auf sein Programm bezogen). Eine Ini der Komponenten wäre auch nicht sinvoll, da ja dann nur eine Verbindung möglich wäre ( bei eigener Ini könnte man ja mehrere alternative Pfade und auch parallele Zugriffe auf mehrere Datenbanken/Bestände ermöglichen

-> genau so. Wichtig ist mir quasi, dass ich ein Programm schreibe und dann nur noch bei Installation beim Kunden entscheiden muss auf welche Variante verbunden wird (Single-User vs. Multi-User)

Zitat:

Zitat von scrat1979

Jein. Wenn Du Befehle benutzt, welche in den entsprechenden DBMS IDENTISCH sind, dann ja. Dann müsstest du Dich allerdings für die Pro-Version entscheiden, da erst hier die entsprechenden Service-Provider für die einzelnen Datenbanksysteme mit ausgeliefert werden. Wie schon gesagt werden von UniDAC allerdings keine DatenbanksystemSPEZIFISCHEN Features unterstützt (z.B. Komponente zur Rechteverwaltung in Firebird)

Nun sagen wir mal so, wenn der "Client" mit der Datenbank nur arbeiten soll (SELECT / INSERT / UPDATE / DELETE) würde es reichen wenn ich keine Komponenten zur Rechteverwaltung habe. Sobald es aber tiefer geht (ALTER TABLE / CREATE TABLE etc.) wird es mit solchen Universallkomponenten schwierig. Außerdem sollte der SQL-Dialekt selbstverständlich der selbe sein. Sonst wird auch das hinfällig (wie ich es auch aus #7 von Bernhard Geyer raus lese). Habe ich das richtig verstanden?

Zitat:

Zitat von mkinzler

Höchstens der Preis (kostenlos). Zeos hat das Problem, dass keine harten Commits unterstützt werden. Was bei Multiuserzugriff ein echtes Problem darstellt.

OK, jetzt fehlt mir das Wissen zu "harten Commits". Commits waren für mich bisher immer die Möglichkeit der DB zu sagen -> übernehme die Änderungen JETZT. Nur wo ist jetzt der Unterschied zwischen hartem und weichem Commit?

Danke an alle für die Rege Teilnahme an meinem "Anfängerproblem".

Chris

[mkinzler]

Zitat:

Also z.B. ZEOS oder IBDAC/UniDAC?

Zeos ist ein Beispiel für die andere Seite -> kostenlos
Ich würde hier zu IBDAC(UnDiAC), FIBPlus o.ä raten.

Zitat:

-> genau so. Wichtig ist mir quasi, dass ich ein Programm schreibe und dann nur noch bei Installation beim Kunden entscheiden muss auf welche Variante verbunden wird (Single-User vs. Multi-User)

Nicht(nur) bei der Installation; kann man flexibel halten.

Zitat:

OK, jetzt fehlt mir das Wissen zu "harten Commits". Commits waren für mich bisher immer die Möglichkeit der DB zu sagen -> übernehme die Änderungen JETZT. Nur wo ist jetzt der Unterschied zwischen hartem und weichem Commit?

Bei Zeos erfolgt der Commit erst beim Schliessen der Verbindung, vorher wird nur ein SavePoint (Teiltransaktion) erzeugt.

Zitat:

Nun sagen wir mal so, wenn der "Client" mit der Datenbank nur arbeiten soll (SELECT / INSERT / UPDATE / DELETE) würde es reichen wenn ich keine Komponenten zur Rechteverwaltung habe. Sobald es aber tiefer geht (ALTER TABLE / CREATE TABLE etc.) wird es mit solchen Universallkomponenten schwierig. Außerdem sollte der SQL-Dialekt selbstverständlich der selbe sein. Sonst wird auch das hinfällig (wie ich es auch aus #7 von Bernhard Geyer raus lese). Habe ich das richtig verstanden?

Auch bei nur "Arbeiten" bekommst du mit den "Spezialisten" weitere Features ( Sequenzverwaltung, Savepoints, Returning, ...). In der Praxis ist der SQL Dialekt der verschiedenen DBMS leider sehr unterschiedlich.

[joachimd]

Zitat:

Zitat von ChrisE

wir brauchen in naher Zukunft eine einfach Datenbanklösung. Ich habe schon versucht mich in verschiedene Bereich ein zu lesen, doch irgendwie überflutten mich die Informationen.
...
Die Anforderungen sind folgende:

• Zugriff von Single-User-Installationen, Mini-Netzen (3-5 Clients) und größeren Netzen bis zu 50 Clients
• Hauptsächlich gibt es lesende Zugriffe, schreiben kann jedoch in "Stoßzeiten" durchaus von allen Clients aus geschehen (quasi-parallel)
• Einfache Installation der Datenbank für Single-User und Mini-Netze - am besten nur durch kopieren von Dateien (ohne Services etc.)
• Simple Umstellung auf größere Netze, die dann wahrscheinlich auf einen Server / Service zugreifen
• Single-User und Mini-Netze am besten ohne zusätzliche Lizenzkosten
• Einsatz in Closed-Source Entwicklung erlaubt

Um auch mal ein kommerzielles Produkt in den Ring zu werfen: Das hört sich wie eine Musteranforderung für den Advantage Database Server an. Und da wird man auch während der Entwicklung und später bei evtl. Supportfällen nicht alleingelassen.

[scrat1979]

Zitat:

Zitat von joachimd

Zitat:

Zitat von ChrisE

wir brauchen in naher Zukunft eine einfach Datenbanklösung. Ich habe schon versucht mich in verschiedene Bereich ein zu lesen, doch irgendwie überflutten mich die Informationen.
...
Die Anforderungen sind folgende:

• Zugriff von Single-User-Installationen, Mini-Netzen (3-5 Clients) und größeren Netzen bis zu 50 Clients
• Hauptsächlich gibt es lesende Zugriffe, schreiben kann jedoch in "Stoßzeiten" durchaus von allen Clients aus geschehen (quasi-parallel)
• Einfache Installation der Datenbank für Single-User und Mini-Netze - am besten nur durch kopieren von Dateien (ohne Services etc.)
• Simple Umstellung auf größere Netze, die dann wahrscheinlich auf einen Server / Service zugreifen
• Single-User und Mini-Netze am besten ohne zusätzliche Lizenzkosten
• Einsatz in Closed-Source Entwicklung erlaubt

Um auch mal ein kommerzielles Produkt in den Ring zu werfen: Das hört sich wie eine Musteranforderung für den Advantage Database Server an. Und da wird man auch während der Entwicklung und später bei evtl. Supportfällen nicht alleingelassen.

... wobei die Datenbank preislich in einer anderen Liga zu spielen scheint :oops:

[ChrisE]

Vielen Dank an alle.

Ich werde mir jetzt weitere Gedanken machen zu den Komponenten. Ich denke Firebird wird die Richtig Wahl sein. Dies werden die Tests aber noch zeigen :-)

:dp:

Chris