Стратегія редагування файлів значень, розділених комами (CSV)

Коли я працюю над проектами з аналізу даних, я часто зберігаю дані у файлах даних, розміщених комами або вкладками (CSV, TSV). Хоча дані часто належать до спеціалізованої системи управління базами даних. Для багатьох моїх заявок це було б надмірним речей.

Я можу редагувати файли CSV та TSV в Excel (або, мабуть, іншій програмі електронних таблиць). Це має переваги:

• електронні таблиці полегшують введення даних

Також є кілька проблем:

• Робота з файлами CSV та TSV призводить до широкого спектру попереджувальних повідомлень про те, що різні функції втрачаються, і як збережеться лише активний аркуш тощо. Таким чином, це прикро, якщо ви просто хочете відкрити файл і внести невеликі зміни.
• Це робить багато "нібито розумних" перетворень. Наприклад, якщо ви введете 12/3, він подумає, що ви хочете ввести побачення. ОНОВЛЕННЯ: Я мав би зазначити, що приклад дати - лише один із багатьох прикладів; Здається, більшість проблем пов'язані з невідповідним конвертацією. Зокрема, текстові поля, схожі на цифри чи дати, викликають проблеми.

Крім того, я міг би працювати безпосередньо з текстовим файлом у стандартному текстовому редакторі. Це гарантує, що те, що я ввожу, - це те, що записується. Однак це дуже незручний спосіб введення даних (стовпці не вирівнюються; важко ввести дані просто у кілька комірок; тощо).

Питання

• Яка хороша стратегія роботи з файлами даних CSV або TSV? тобто яка стратегія полегшує введення та маніпулювання даними, одночасно гарантуючи, що те, що ви вводите, насправді інтерпретується правильно?

1. Якщо вам подобається R, ви можете створити свій базовий data.frame, а потім використовувати функцію fix () для введення даних. Після того самого рядка, що і №5, після встановлення data.frame ви можете використовувати серію readLines (n = 1) (або що завгодно), щоб отримати ваші дані, перевірити їх і надати можливість додати наступні ряд. Потім залиште кріплення для виправлення (). Дивіться реалізований приклад нижче, використовуючи scan ().

2. Інший варіант у excel був би безладним, але ви можете ввести 12/9, а потім мати інший стовпець оцінки = IFERROR (MONTH (DateEntryCell) / DAY (DataEntryCell), DataEntryCell). Але тоді вам доведеться підтримувати лист excel І аркуш csv, і всі скарги під час написання CSV зберігатимуться.

3. Крім того, якщо ваші поля відносно короткі та мають послідовну довжину, звичайний редактор тексту повинен добре працювати з TSV. Ви завжди можете завантажити його в excel, коли закінчите, і переконайтеся, що кількість стовпців для кожного рядка - це те, що ви очікуєте.
4. Emacs доступний на багатьох платформах і, ймовірно, має щось саме для цього, наприклад, http://www.emacswiki.org/emacs/CsvMode .
5. Якщо ви душевна душа, програмувати щось швидке на мові програмування, щоб зробити введення даних тривіально, редагування даних буде набагато важче.
6. Швидкий пошук у Google показує програмне забезпечення саме з цією метою, але жодне вільне програмне забезпечення не здавалося б корисним.
7. Це звучить божевільно, але хтось із суперпопулярних запропонував редагувати таблиці в доступі, а потім експортувати їх у форматі CSV ... це достатньо шалено для роботи.
8. Це не перешкоджає скаргу, коли ви зберігаєте як .csv, але ви можете ввести один апостроф перед полем для введення даних, і це змусить його залишити його в спокої з точки зору автоматичного форматування. Приємно, що це (принаймні в Office 2007) не залишає апостроф у файлі csv.

Оновлення: Я дуже багато роздумував над цією проблемою, тому що це теж проблема. На сьогодні найкращим / найпростішим рішенням для введення даних, який я бачив, є KillinkCSV . Це не "безкоштовне" програмне забезпечення, це програмне забезпечення із тривалістю пробного періоду 30 днів та розумною ціною (~ 27 доларів). Я не впевнений, наскільки я їй довіряю для редагування існуючих CSV-файлів - я передав йому шалено великий (і, мабуть, добре відформатований) CSV, і він не зміг прочитати всі рядки. Однак, здавалося, добре працює для одного, який був досить великим (20 Мб), і проблема з більшим файлом може бути помилкою користувача з мого боку.

Приклад R:

#This function takes a what argument like in scan, 
#a list with the types to be used, see usage example 
#at the end of this code block
#dataEntry will keep reading in values until 
#the values it reads in matches what is in 
#"terminateon".
#limitations: Many
dataEntry <- function(what,terminateon)
{
  CONTINUE <- TRUE #Make sure we start the loop
  data <- NULL #Create empty data so that the data.frame can define itself
  ti <- NULL
  while(CONTINUE)
  {
    ti <- NULL    
    ti <- tryCatch(
      {as.data.frame(scan(what=what, nlines=1, multi.line=FALSE, comment.char="",quiet=TRUE))},
      error=function (e) {print("Error in data entry! Line not stored.")
                          return(NULL)},
      warning=function(w) {print("Error in data entry! Line not stored.")
                           return(NULL)},
      finally={ti <- NULL}
    ) #Try getting the data according to the parameters in 'what' one row at a time.
    if (!is.null(ti))
    {
      if ((ncol(ti)==length(what)) & (nrow(ti)==1)) {
        data <- rbind(data,ti) #If there wasn't an error, add ti to the previous value  
      } else {
        print("Too many or not enough values on previous entry.")
        print("Tail of current data:")
        print(tail(data))
      }
    }
    if (!is.null(ti) & all(ti == terminateon)) 
    {
      CONTINUE <- FALSE
      data <- data[-c(nrow(data)),]
    } #if we've recieved the final value we won't continue and the last row is invalid so we remove it
  }
  return(data)
}

dataEntry(list(x=integer(), y=numeric(), z=character()),terminateon=c(999,999,"Z"))

Оновлення: [Переглянувши великий відсталий лист електронної пошти від R-Help], мені нагадали тему на тему " Поведінкаread.csv() ". У цьому Данкан Мердок згадує, що вважає за краще використовувати файли формату обміну даними (DIF) замість csv з якоїсь причини, про яку згадує Джеромі. Я просто спробував це, і Gnumeric помиляється (завантажує 12/3 як дату), але OpenOffice.org читає це правильно і зберігає 12/3 інформацію неушкодженою. (Хтось турбується перевірити це в MS Excel?)

Файли DIF - це звичайний текст і може читатись за допомогою електронних таблиць і R (доки ви використовуєте нещодавню R-версію (SVN-версія> = r53778)) буде читати дані у правильному форматі.

Оригінал : Я б намагався уникати використання повної зупинки електронної таблиці для редагування / маніпулювання даними, коли це можливо. Неймовірно важко, якщо не неможливо, задокументувати будь-які внесені вами зміни до наявного набору даних, так що вони значною мірою виключають це з точки зору відтворюваного дослідження. Щонайбільше я використовую електронну таблицю для швидкого перегляду наявних даних.

Для обробки даних я, як правило, пишу сценарій R, який візьме необроблений файл csv та застосує всі необхідні кроки обробки. Я сильно коментую цей сценарій, щоб пояснити, що саме я роблю на кожному етапі і чому. Потім мій скрипт аналізу даних викликав би сценарій обробки даних, який завантажує та обробляє дані.

Що стосується введення даних, чи більше клопоту вводити дані в текстовий редактор або в електронну таблицю? Я підозрюю, що проблеми, які ви згадуєте для останніх, не переважають проблем спроб ввести дані CSV в текстовий редактор.

Ви можете спробувати кращу електронну таблицю; OpenOffice.org відмовляється зупинити форматування 12/3 як дату (або перетворює її в числове представлення), навіть якщо спершу сформулює стовпець як "числовий". З іншого боку, Gnumeric залишить 12/3 таким, як це буде, якщо спершу відформатувати стовпець як "числовий".

Ви можете змусити OpenOffice.org не переформатувати 12/3 як дату, попередньо додавши 'до записів, тобто '12/3відображатиметься як 12/3 в електронній таблиці та зберігається як текст. Це, ймовірно, досить безпечно у використанні.

Не впевнений, чому ви хочете, щоб 12/3 зберігалися в текстовому файлі в цифрі як 12/3 - як це має читати щось на зразок R?

Ваш коментар щодо попереджень про втрату функцій або збереження лише активного аркуша насправді не проблема? (Якщо вони є, то я хочу, щоб у вашому житті були проблеми ;-)

Я пропоную вам переглянути уточнення google (http://code.google.com/p/google-refine/). Я думаю, що це дуже хороший інструмент для редагування файлів CSV

Я б уникнув спільної роботи з файлами CSV та TSV. Натомість навчіться використовувати SQL і працювати лише на копії даних або базі даних (БД), або ви можете використовувати SAS або R із підключенням до вашої бази даних. Таким чином ви можете робити масові оновлення своїх даних, замість того, щоб не боятися знаходити та замінювати в Excel (або будь-якій програмі електронних таблиць, яку ви використовуєте), або копіювати та вставляти, які можуть бути схильними до помилок. Перевага використання системи DB також полягає в тому, що ви можете ввімкнути журнал та швидко змінити відкат, які ви внесли, якщо вони були зроблені помилково, і всі зміни можна перевірити. Крім того, обмеження цілісності можуть бути розміщені у ваших таблицях БД, щоб гарантувати помилкове оновлення чи зміну змінних / стовпців способами, які ви вважаєте недоречними (наприклад, дати залишаються як дати та інша інформація надається належним чином). Я виграв'

Якщо вам подобаються електронні таблиці, оскільки це якимось чином сприяє введенню даних, це можна подолати у будь-якій базі даних, яку я коли-небудь використовував, використовуючи інструменти / IDE графічного користувальницького інтерфейсу, що постачаються з базами даних (наприклад, Microsoft Management Studio) або перетягуючи пов'язану версію вашої бази даних в систему, спеціально розроблену для введення ваших даних та забезпечення обмежень даних (наприклад, пов'язані форми таблиць у Access або користувальницький веб-інтерфейс). Ви також можете використовувати інші програми, які дозволять вам отримати найкраще з обох світів та оновлювати дані в Excel, а ці зміни поширюватимуться у вашій базі даних (див. Https://www.youtube.com/watch?v=5iyuF_mDSac наприклад) .

Після того, як я задав це питання, я почав переглядати CSVed .

З веб-сайту:

CSVed - це простий та потужний редактор файлів CSV, ви можете маніпулювати будь-яким файлом CSV, розділеним будь-яким роздільником.

Я не впевнений, чи має хто з цим досвід.

Excel не дуже зручний для CSV. Наприклад, якщо ви повинні ввести "1300" в Excel і зберегти це як значення, відокремлене комою, це дозволить вам! Це може бути великою проблемою (я стикаюся з цим регулярно, коли отримую файли від інших).

Я особисто використовую OpenOffice.org Calc, я також використовую багато перерахованих вище рішень, однак багато з них не мають функціоналу та простоти використання, необхідних для регулярного редагування. OOO Calc набагато розумніший за Excel, хоча, будучи програмою електронних таблиць, вам все одно доведеться вводити "= 12/3" замість "12/3", інакше ви будете вводити значення, а не обчислення.

Дайте йому кружляння, ви не розчаруєтесь.

Мені подобається Gnumeric, оскільки він не намагається бути настільки стійким до ідіотів, як інші (він не кричить про втрату функціональності) і працює з великими даними ... все ж я думаю, що це лише Linux.

Просто скористайтеся редактором Рона . Це так само, як Excel без "допомоги".

З сайту:

Редактор Рона - це потужний табличний текст або редактор CSV. Він може відкрити будь-який формат відокремленого тексту, включаючи стандартні файли, розділені комами та вкладками (CSV та TSV), і дозволяє повністю контролювати їх вміст та структуру.

Не тільки можна редагувати табличні текстові файли, але вони також можуть бути легко відфільтровані та узагальнені у скільки завгодно додаткових представлень, додаючи потужний функціонал аналізу.

• Ліцензія: безкоштовно для особистого використання / оцінки
• Запускається: Windows 32/64-розрядна версія 2000 / XP / 2003 / Vista /

Мені особисто подобається використовувати ідею "реляційної бази даних" для управління файлами CSV. CSV-файли хороші для обміну даними, але не містять ділової логіки. Мій досвід роботи з CSV полягає в тому, що "з бізнесом є багато ітерацій для вдосконалення аналізу". Робота з лише текстовими файлами простого формату (CSV) поставить безліч проблем. Наприклад, файл CSV не відображатиме "те, що робить дані унікальними", тобто що є "первинним ключем до кожного рядка". Це спричинить великі проблеми пізніше, коли у нас з’явиться інше джерело даних.

SQLite - це хороший інструмент для перетворення CSV у реляційну базу даних, і подібний до CSV, його легко обміняти, і сервер не налаштований. Що ще важливіше, він дуже добре підтримував Rстатистичне програмне забезпечення.

Моя стратегія - це завжди підтримувати "очищені дані" у реляційній базі даних. І тримайте це чітко в первинному ключі кожної таблиці.

Ось приклад того, що може статися справжнім словом (припустимо, ми продаємо книги):

• 1-го дня я отримав файл CSV, який містить всю інформацію про клієнтів.
• 2-го дня я отримав ще один файл CSV, який містить всю інформацію про товар (книгу). З якоїсь причини компанія сказала, що немає ISBN, а поєднання назви книги та імені автора є первинним ключем.
• Третій день, видання, яке знайдено в бізнесі, потрібно враховувати, вони надсилають інший CSV, щоб "перезаписати" CSV day2.
• День 4, Інформація про клієнтів, знайдена компанією, може бути оновлена ​​(наприклад, зміна адреси), вони надсилають оновлену версію інформації про клієнтів.

Тепер ви можете бачити перевагу чистих даних та зберігати їх у реляційній базі даних. Ідентифікатор клієнта скажіть як первинний ключ, а ім’я книги, автор та видання як первинний ключ. Дуже легко робити оновлення даних та включати зміни за потребою. Також первинний ключ також дає "обмеження" та "перевірку правильності" для нових даних, що надходять.

Якщо ви використовуєте функцію "Імпорт даних" Excel, вона надасть вам можливість вибору типу даних для кожного стовпця. Ви можете вибрати всі стовпці та використовувати тип даних «Текст».