Sqlite как замена для fopen ()?
> dat <- tibble(H = c("6'2\"", "5'10\"", "5'5\"", "5'1\"", "5'5\"", "5'4\""))
> dat$inches <- gsub("[\"]", "",dat$H) %>%
strsplit(., "'") %>%
lapply(., function(x) {
x <- as.numeric(x);
(x[1]*30.48) + (x[2]/12)*30.48
}) %>%
unlist
> dat
# A tibble: 6 x 2
H inches
<chr> <dbl>
1 "6'2\"" 188.
2 "5'10\"" 178.
3 "5'5\"" 165.
4 "5'1\"" 155.
5 "5'5\"" 165.
6 "5'4\"" 163.
Вы даже можете использовать map вместо lapply
> gsub("[\"]", "",dat$H) %>%
strsplit(., "'") %>%
map_dbl(function(x){
x <- as.numeric(x)
(x[1]*30.48) + (x[2]/12)*30.48
})
[1] 187.96 177.80 165.10 154.94 165.10 162.56
4 ответа
Это зависит. Существуют некоторые противопоказания:
для конфигурационных файлов использование простого текста или XML намного легче отладить или измениться, чем использование реляционной базы данных, даже один столь же легкий как SQLite.
древовидные структуры легче описать использование (например), XML, чем при помощи реляционных таблиц
API SQLite вполне плохо документируется - существует недостаточно примеров, и связывание гиперссылками плохо. OTOH, информация - все там, если Вы хотите вырыть для него.
использование определенных для приложения двоичных форматов непосредственно будет быстрее, чем хранение того же формата как BLOB в базе данных
повреждение базы данных может означать Лос из всех Ваших данных, а не этого в единственном плохом файле
OTOH, если Ваши внутренние совпадения данных в хорошо с реляционной моделью и если бы существует многое из него, я рекомендовал бы SQLite - я использую ее сам для одного из моих проектов.
Относительно опыта - я использую его, это работает хорошо и легко интегрироваться с существующим кодом. Если бы по документации было легче переместиться, то я дал бы ей 5 звезд - как это, я дал бы она четыре.
Поскольку всегда это зависит, нет никаких "единых" решений
Если необходимо хранить данные в автономном файле, и можно использовать в своих интересах возможности реляционной базы данных базы данных SQL, чем SQLite является большим.
Если Ваши данные не являются подходящим вариантом для реляционной модели (иерархические данные, например), или Вы хотите, чтобы Ваши данные были по-человечески читаемы (файлы конфигурации), или необходимо взаимодействовать с другой системой, чем SQLite не будет очень полезен, и XML мог бы быть лучше.
Если, с другой стороны, необходимо получить доступ к данным из нескольких программ или компьютеров одновременно, чем снова SQLite не является оптимальным выбором, и Вам нужен "реальный" сервер базы данных (MS SQL, Oracle, MySQL, PosgreSQL...).
Атомарность SQLite плюс. Знание, что, если Вы на полпути пишете некоторые данные (возможно, катастрофический отказ в середине), что это не повредит Ваш файл данных. Я обычно выполняю что-то похожее с xml файлами конфигурации путем резервного копирования файла на успешной загрузке и любого будущего, отказавшая загрузка (указание на повреждение) автоматически восстанавливает последнее резервное копирование. Конечно, это не столь детализировано, и при этом это не является атомарным, но это достаточно для моих требований.
Я нахожу SQLite удовольствием работать с, но я не считал бы это единой заменой для fopen ().
Как пример, я просто записал часть программного обеспечения, это загружает изображения с веб-сервера и кэширует их локально. Храня их как отдельные файлы, я могу наблюдать их в Windows Explorer, который, конечно, обладает преимуществами. Но я должен сохранить индекс, который отображается между URL и файлом изображения для использования кэша. Храня их в базе данных SQLite, они все находятся в одном аккуратном небольшом файле, и я могу получить доступ к ним URL (выберите imgdata из кэша где URL ='http://foo.bar.jpg') с небольшим усилием.
