Η εισαγωγή ενός CSV μοιάζει με απλή λειτουργία: ανεβάζουμε αρχείο, αντιστοιχίζουμε στήλες και πατάμε «Import». Στην πράξη, το αρχείο μπορεί να έχει διαφορετικό encoding, ημερομηνίες σε πολλές μορφές, κενά IDs, διπλούς πελάτες και τιμές που μοιάζουν με αριθμούς αλλά δεν πρέπει να χάσουν τα αρχικά μηδενικά τους.
Σε CRM, e-shop και portals, ένα πρόχειρο import μπορεί να δημιουργήσει μεγαλύτερο πρόβλημα από αυτό που λύνει. Χρειάζεται pipeline με προεπισκόπηση, σαφή validation, ασφαλή επανάληψη και δυνατότητα να γνωρίζουμε ακριβώς ποιες εγγραφές δημιουργήθηκαν ή άλλαξαν.
Το CSV δεν είναι τόσο ενιαίο όσο φαίνεται
Το RFC 4180 καταγράφει μια κοινή μορφή CSV με γραμμές, διαχωριστικά, προαιρετική κεφαλίδα και escaping πεδίων με διπλά εισαγωγικά. Παράλληλα αναγνωρίζει ότι υπάρχουν σημαντικές διαφορές μεταξύ υλοποιήσεων.
Στην καθημερινή χρήση συναντάμε κόμμα ή ελληνικό ερωτηματικό ως separator, UTF-8 ή παλιότερα encodings, line endings διαφορετικών λειτουργικών, δεκαδικά με κόμμα, ημερομηνίες ημέρα/μήνας ή μήνας/ημέρα και κελιά με αλλαγές γραμμής. Γι' αυτό το parsing πρέπει να γίνεται με δοκιμασμένη CSV βιβλιοθήκη και όχι με split σε χαρακτήρες.
1. Ασφαλής παραλαβή αρχείου
Η εφαρμογή ελέγχει τύπο, πραγματικό περιεχόμενο, μέγεθος, αριθμό γραμμών και επιτρεπόμενο encoding. Το αρχείο αποθηκεύεται προσωρινά με μη προβλέψιμο όνομα και δεν εκτελείται ούτε δημοσιεύεται σε δημόσιο URL.
Για μεγάλα αρχεία, η επεξεργασία πρέπει να γίνεται streaming ή σε batches. Η φόρτωση ολόκληρου του CSV στη μνήμη μπορεί να εξαντλήσει το process. Το upload δημιουργεί import job και ο χρήστης βλέπει πρόοδο αντί να περιμένει ένα HTTP request πολλών λεπτών.
2. Ανίχνευση και επιβεβαίωση δομής
Το σύστημα μπορεί να προτείνει separator, encoding και αν η πρώτη γραμμή είναι header, αλλά ο χρήστης πρέπει να τα επιβεβαιώνει όταν υπάρχει αβεβαιότητα. Μια προεπισκόπηση των πρώτων γραμμών αποκαλύπτει αμέσως αν οι ελληνικοί χαρακτήρες αλλοιώθηκαν ή αν όλες οι τιμές μπήκαν σε μία στήλη.
Οι κενές γραμμές, οι στήλες χωρίς όνομα και οι διπλές επικεφαλίδες χρειάζονται σαφή χειρισμό. Δεν πρέπει να αλλάζει σιωπηρά η σημασία του αρχείου.
3. Mapping στηλών σε πεδία
Ο χρήστης αντιστοιχίζει «Email πελάτη» σε email, «Κωδικός» σε SKU και «Κινητό» σε phone. Το σύστημα μπορεί να προτείνει mapping από γνωστά aliases, αλλά δεν πρέπει να μαντεύει αμετάκλητα.
Κάθε target field δείχνει τύπο, αν είναι υποχρεωτικό και παράδειγμα. Τα saved mappings βοηθούν σε επαναλαμβανόμενα imports από τον ίδιο προμηθευτή. Χρειάζονται versioning, επειδή το schema της εφαρμογής και οι στήλες του συνεργάτη αλλάζουν με τον χρόνο.
4. Κανονικοποίηση πριν από το validation
Η κανονικοποίηση μετατρέπει ισοδύναμες τιμές σε συνεπή μορφή χωρίς να αλλοιώνει τα δεδομένα. Ενδεικτικά:
- αφαιρεί περιττά εξωτερικά κενά,
- κανονικοποιεί email για σύγκριση,
- μετατρέπει τηλέφωνα σε συμφωνημένη μορφή,
- αναγνωρίζει ημερομηνίες μόνο με ρητή locale,
- διατηρεί IDs και ταχυδρομικούς κώδικες ως strings,
- αντιστοιχίζει επιτρεπόμενες τιμές κατάστασης μέσω lookup table.
Η αρχική τιμή πρέπει να παραμένει διαθέσιμη στην αναφορά λαθών. Αν το import απορρίψει μια ημερομηνία, ο χρήστης χρειάζεται να δει ακριβώς τι υπήρχε στο κελί.
5. Validation σε επίπεδο πεδίου και εγγραφής
Το validation ελέγχει τύπο, μήκος, απαιτούμενα πεδία, επιτρεπόμενες τιμές και αναφορές σε υπάρχοντα δεδομένα. Στη συνέχεια εφαρμόζει επιχειρηματικούς κανόνες: ένα variant χρειάζεται υπαρκτό product, μια παραγγελία δεν μπορεί να έχει αρνητική ποσότητα και μια επαφή πρέπει να ανήκει στον σωστό tenant.
Τα λάθη επιστρέφονται με αριθμό γραμμής, στήλη, αρχική τιμή και σαφή μήνυμα. Το «Invalid row» δεν βοηθά κανέναν. Ιδανικά ο χρήστης κατεβάζει αρχείο μόνο με τις αποτυχημένες γραμμές και διορθώνει συγκεκριμένα προβλήματα.
6. Deduplication και ταυτότητα εγγραφής
Πριν την εισαγωγή ορίζεται τι κάνει μια εγγραφή μοναδική. Σε προϊόντα μπορεί να είναι SKU ή εξωτερικό ID. Σε πελάτες μπορεί να είναι customer ID, email ή συνδυασμός πεδίων. Το όνομα μόνο του σπάνια αρκεί.
Η πολιτική πρέπει να ξεχωρίζει:
- create: δημιουργία μόνο νέων εγγραφών,
- update: ενημέρωση μόνο όταν βρεθεί συγκεκριμένο κλειδί,
- upsert: δημιουργία ή ενημέρωση,
- skip: παράλειψη διπλοτύπων,
- merge candidate: αποστολή αμφίβολης αντιστοίχισης για ανθρώπινο έλεγχο.
Το fuzzy matching δεν πρέπει να ενώνει αυτόματα πελάτες με παρόμοιο όνομα. Μια λανθασμένη συγχώνευση μπορεί να εκθέσει ιστορικό ή προσωπικά δεδομένα σε άλλο άτομο.
7. Preview και dry run
Πριν γραφτεί οτιδήποτε, το σύστημα παρουσιάζει πόσες εγγραφές θα δημιουργηθούν, θα ενημερωθούν, θα παραλειφθούν ή θα αποτύχουν. Δείχνει δείγματα αλλαγών, ειδικά όταν το import πρόκειται να αντικαταστήσει υπάρχουσες τιμές.
Το dry run πρέπει να χρησιμοποιεί τους ίδιους κανόνες με το πραγματικό import. Αν η προεπισκόπηση έχει διαφορετική υλοποίηση, μπορεί να εγκρίνει αρχείο που αποτυγχάνει αργότερα.
8. Atomicity, batches και rollback
Για μικρό αρχείο μπορεί να χρησιμοποιηθεί μία transaction: όλα επιτυγχάνουν ή τίποτα δεν αλλάζει. Για εκατοντάδες χιλιάδες γραμμές, μια τεράστια transaction κρατά locks, αυξάνει WAL και κάνει δύσκολη την ανάκαμψη.
Τότε χρησιμοποιούνται batches με checkpoint και import ID. Κάθε αλλαγή συνδέεται με το job, ώστε να μπορεί να γίνει αντιστροφή όπου είναι ασφαλές. Rollback δεν σημαίνει πάντα απλή διαγραφή: αν μια εγγραφή ενημερώθηκε μετά το import από χρήστη, χρειάζεται conflict policy και audit trail.
9. Idempotency και επανάληψη
Αν το job διακοπεί στη μέση, η επανεκκίνηση δεν πρέπει να διπλασιάσει δεδομένα. Κάθε γραμμή μπορεί να έχει fingerprint ή συνδυασμό import ID και row number. Τα upserts πρέπει να βασίζονται σε σταθερά external IDs και όχι σε τυχαία πεδία.
Η κατάσταση job περιλαμβάνει pending, validating, ready, importing, completed, failed και canceled. Ο χρήστης πρέπει να γνωρίζει αν μια αποτυχία συνέβη πριν ή μετά την εγγραφή δεδομένων.
10. Ασφάλεια και CSV formula injection
Ένα πεδίο CSV μπορεί να αρχίζει με χαρακτήρα που ένα spreadsheet ερμηνεύει ως formula. Η OWASP περιγράφει το CSV injection ως κίνδυνο όταν μη έμπιστα δεδομένα ενσωματώνονται σε CSV και ανοίγονται σε Excel ή άλλο spreadsheet.
Αυτό αφορά και τα imports: μια κακόβουλη τιμή μπορεί να αποθηκευτεί στο CRM και αργότερα να εξαχθεί σε αρχείο που ανοίγει η ομάδα. Χρειάζεται πολιτική ασφαλούς export, έλεγχος αρχικών χαρακτήρων και ενημέρωση ότι δεν υπάρχει μία καθολική μέθοδος sanitization που να ταιριάζει σε κάθε spreadsheet και downstream χρήση.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry σχεδιάζουμε imports ως ελεγχόμενα data workflows. Υλοποιούμε streaming parsing, mapping με αποθηκευμένα templates, validation δύο επιπέδων, dry run και αναλυτικές αναφορές ανά γραμμή.
Ορίζουμε μαζί με την επιχείρηση τα πραγματικά uniqueness rules και αποφεύγουμε επικίνδυνες αυτόματες συγχωνεύσεις. Προσθέτουμε idempotency, audit trail, checkpoints και ασφαλές rollback ανάλογα με το μέγεθος του αρχείου. Έτσι η Ai Foundry είναι ισχυρός συνεργάτης για CRM, e-shop και portals που χρειάζονται επαναλαμβανόμενες εισαγωγές χωρίς να θυσιάζουν την ποιότητα των δεδομένων.
Checklist πριν ενεργοποιηθεί το import
- Χρησιμοποιήστε κανονικό CSV parser και υποστηρίξτε ρητό encoding.
- Προβάλετε separator, header και δείγμα πριν το mapping.
- Διατηρήστε τις αρχικές τιμές για debugging.
- Ορίστε μοναδικά κλειδιά και πολιτική create, update ή upsert.
- Εκτελέστε dry run με τους ίδιους production κανόνες.
- Επιστρέψτε λάθη ανά γραμμή και στήλη.
- Κάντε μεγάλα imports σε batches με checkpoints.
- Συνδέστε κάθε αλλαγή με import ID και audit log.
- Ελέγξτε formula injection σε μελλοντικά exports.
Το καλό bulk import δεν είναι αυτό που «κατάπιε» όλες τις γραμμές. Είναι αυτό που μπορεί να εξηγήσει τι άλλαξε, τι απορρίφθηκε και πώς θα επαναληφθεί με ασφάλεια.