Eine Datenquelle verbinden
Verbindungen sind das erste Stück Plattformzustand, von dem Ihre Dashboards abhängen, und die klarste Illustration der Aufteilung: Das Dashboard ist Code, den Ihr Agent schreibt und innerhalb einer Minute umschreiben kann; die Verbindung ist ein Zugangsdatum, ein Netzwerkpfad und ein introspektiertes Schema, das jemand einmal eingerichtet hat und das ein Jahr lang weiterlaufen muss.
Sie richten eine Verbindung einmal ein. Von da an fragt jede Oberfläche darüber ab — Ihr Agent über MCP, Ihr Code über die SDKs, der In-App-Assistent und jedes veröffentlichte Dashboard.
Was Sie verbinden können
Vibedasher verfügt über 20 Verbindungstypen. Neunzehn haben eine funktionierende Service-Implementierung, und neunzehn werden heute in der Konnektor-Auswahl der App angeboten. Der Unterschied ist wichtig, wenn Sie das Produkt gegen eine bestimmte Quelle bewerten, deshalb hier die vollständige Liste statt einer Marketing-Zahl.
Datenbanken und Warehouses
| Quelle | In der Auswahl | Inkrementelle Ladevorgänge |
|---|---|---|
| PostgreSQL | ja | ja |
| MySQL | ja | ja |
| SQL Server (MSSQL) | ja | ja |
| Oracle | ja | ja |
| Redshift | ja | ja |
| Snowflake | ja | ja |
| BigQuery | ja | ja |
| Athena | ja | ja |
| MongoDB | ja | nein |
| Cassandra | ja | nein |
| DynamoDB | ja | nein |
SaaS und Dateispeicher
| Quelle | In der Auswahl | Inkrementelle Ladevorgänge |
|---|---|---|
| Salesforce | ja | nein |
| HubSpot | ja | nein |
| Marketo | ja | nein |
| Mailchimp | ja | nein |
| Google Sheets | ja | nein |
| Google Analytics | ja | nein |
| Azure Data Lake | ja | nein |
| Google Cloud Storage | ja | nein |
| SAP | nein | nein |
SAP benötigt pyrfc, SAPs proprietäres NetWeaver-RFC-SDK, das nicht auf PyPI liegt — der
Konnektor ist daher nicht ausgeliefert. Auf Altkonten existiert noch eine sap-Verbindungszeile,
und die Schema-Introspektion darauf antwortet mit 404.
Flatfile-Upload
Der Upload akzeptiert CSV (.csv) und Excel (.xlsx, .xls).
Parquet ist kein Upload-Format. Vibedasher speichert Ihre Daten intern als Parquet, aber hochladen können Sie es nicht. Wenn Ihre Daten bereits als Parquet vorliegen, legen Sie sie in einem Speicher ab, den Vibedasher abfragen kann, oder konvertieren Sie sie in CSV.
Inkrementelle Ladevorgänge brauchen einen SQL-Dialekt
Die Spalte Inkrementelle Ladevorgänge oben ist keine Produktentscheidung, sondern eine mechanische. Ein inkrementeller Ladevorgang funktioniert, indem Ihre Extraktionsabfrage um ein Wasserzeichen-Prädikat erweitert wird, und diese Umschreibung braucht einen SQL-Dialekt, den die Plattform parsen kann. Acht Konnektoren haben einen — PostgreSQL, MySQL, SQL Server, Oracle, Redshift, Snowflake, BigQuery und Athena.
Jeder andere Konnektor, einschließlich MongoDB, DynamoDB und aller SaaS-Quellen,
aktualisiert per vollständigem Neuladen. Das ist korrekt, nur teurer: Planen Sie dafür
bei einer großen Quelle, und siehe
Ihre Daten aktuell halten, was effectiveMode zurückmeldet.
Eine Verbindung hinzufügen
- Öffnen Sie die App unter cloud.vibedasher.com und gehen Sie zu Verbindungen.
- Wählen Sie den Quelltyp und füllen Sie die Verbindungsdetails aus — oder laden Sie Ihre Datei hoch.
- Führen Sie Verbindung testen aus. Das öffnet tatsächlich die Verbindung; es ist keine reine Feldformatprüfung.
- Speichern. Vibedasher introspektiert das Schema, damit Agenten und die Query-Engine wissen, welche Tabellen und Spalten existieren.
Gespeicherte Zugangsdaten werden in der Benutzeroberfläche maskiert. Wenn Sie eine Verbindung bearbeiten, lassen Sie ein maskiertes Feld unangetastet, um den bestehenden Wert zu behalten — die Plattform erkennt die Maskierung beim Zurückschreiben und behält, was sie bereits hat, statt Ihr Passwort mit einer Reihe von Punkten zu überschreiben.
Das alles können Sie auch aus dem Code heraus tun:
schema = client.connections.get_schema(connection_type, connection_id)
tables = client.connections.get_tables(connection_type, connection_id)
const schema = await client.connections.getSchema(connectionType, connectionId);
const tables = await client.connections.getTables(connectionType, connectionId);
Die vollständige Menge — create, list, get, update, updateMetadata, delete,
test, getSchema, getTables, getTableSchema, validateQuery — finden Sie in der
API Reference.
Wer eine Verbindung verwalten darf
Verbindungen sind nicht vom Ordner-Zugriffsrechte-Modell abgedeckt — es gibt keine verbindungsbezogene Berechtigung. Die Regeln sind einfacher und es lohnt sich, sie klar auszusprechen:
- Jeder Creator oder Admin darf eine Verbindung erstellen. Ein Viewer darf das nicht.
- Nur der Eigentümer der Verbindung oder ein Admin darf sie aktualisieren oder löschen.
- Eine Verbindung ist für den Rest des Kontos nicht sichtbar, wie es bei einem geteilten Ordner der Fall wäre.
Wenn Sie eine Verbindung benötigen, die mehrere Personen verwalten können, sollte ein Admin sie besitzen. Siehe Wer sieht was für den Rest des Berechtigungsmodells.
Datensätze
Eine Verbindung ist ein Weg zu Ihren Daten; ein Datensatz ist das, was Dashboards tatsächlich lesen. Sie erstellen Datensätze aus einer Verbindung — eine Tabelle oder das Ergebnis einer Abfrage.
Jeder Datensatz erhält einen cleanSQLName-Alias, der der Tabellenname ist, gegen den Ihr
Agent SQL schreibt. Ein Datensatz durchläuft PENDING → DOWNLOADING → PROCESSING → READY,
und ein Dashboard, das auf einem Datensatz aufbaut, der READY noch nicht erreicht hat,
hat nichts zu zeichnen. Warten Sie auf READY.
Datensätze sind lebender Zustand, keine einmaligen Importe: Lösen Sie eine Aktualisierung aus, um einen voranzubringen, und führen Sie nachgelagert dbt-Projekte aus. Dashboards übernehmen aktualisierte Daten über dieselbe Query-Engine, ohne Neu-Build — was der ganze Grund ist, warum die Datenhälfte hier lebt und nicht in der Sitzung Ihres Agenten.
Nächster Schritt
Richten Sie Ihren Agenten auf den Datensatz aus — Mit Ihrem Agenten bauen (MCP) — oder richten Sie Ihren Agenten darauf aus. Richten Sie dann Aktualisierungen ein, damit es wahr bleibt.