Базы данных по сравнению с простым текстом
Вам нужно:
#convert column to numeric
df['Price'] = df['Price'].str.replace(',','.').astype(float)
#get top2 values from index
print (df['Price'].value_counts().iloc[:2])
78.0 3
199.0 3
Name: Price, dtype: int64
#filter rows with top2 values (78, 199)
df = df[df['Price'].isin(df['Price'].value_counts().iloc[:2].index)]
print (df)
InvoiceId StockCode Price
0 XXX ProductA 199.0
1 XXX ProductB 78.0
3 YYY ProductB 78.0
4 YYY ProductA 199.0
5 ZZZ ProductA 199.0
6 ZZZ ProductB 78.0
#count top2
df1 = pd.crosstab(df['InvoiceId'],
df['StockCode'])
print (df1)
StockCode ProductA ProductB
InvoiceId
XXX 1 1
YYY 1 1
ZZZ 1 1
14 ответов
1) Параллелизм. У Вас есть несколько человек, получающих доступ к тому же набору данных? Затем это собирается довольно принять участие для посредничества во всех различных средствах чтения и устройствах записи в масштабируемый вид если Вы система самокрутки.
2) Форматирование и отношения: Ваши данные - что-то, что не соответствует аккуратно структуре таблицы? Длинные последовательности нуклеотида и материал как этот? Это не действительно удобно табличные данные.
Другой пример: Никто не полагал бы, что программное обеспечение реализации как Photoshop хранит PSDs в реляционном формате, потому что структуры данных действительно не предоставляют себя тому типу устройства хранения данных или запрашивают шаблон.
3) ACID (вид заключения к № 1): Если Атомарность, Непротиворечивость, Целостность и Длительность не являются проблемами с плоским файлом, то пойдите с плоским файлом.
Я думаю в какой-то момент, что Вы пропустите возможности запросов базы данных, но можно рассмотреть некоторые минималистические альтернативы базы данных:
- SQLite (Большой, почти совместимый стандарт SQL-92)
- shsql
- SQL Server, Компактный
Для меня пересечена строка, после того как я должен запросить свои данные способами, которые включают больше, чем единственные отношения. Связь двух плоских структур данных на диске довольно проста, но после того как мы добираемся кроме того, основанный на наборе язык как SQL и формальные отношения базы данных на самом деле уменьшает сложность.
Проблема с маленькими проектами состоит в том, что они становятся больше, прежде чем мы будем знать это. И после того как они делают, мы начинаем пропускать sql возможности.
Всегда разрабатывают таким образом, что дб может быть использован позже при необходимости, не разрывая половину приложения.
Я только записал бы свой собственный дисковый формат при совершенно особых обстоятельствах. Многократное использование чужого кода почти всегда быстрее.
Для реляционных данных, я использовал бы SQLite. Для пар ключ/значение я использовал бы BerkeleyDB (возможно, через KiokuDB). Для простых объектов я использовал бы JSON или YAML, но только если у меня только были некоторые.
С SQLite и BDB, "реальная база данных" является буквально двумя строками кода далеко. Трудно разбить это.
Это зависит полностью от проблемно-ориентированных потребностей приложения. Большой доступ файла/двоичных файлов простого текста времен может быть чрезвычайно быстрым, эффективным, а также если Вы все возможности доступа к файлу файловой системы Вашей ОС.
, Кроме того, Ваш язык программирования, скорее всего, уже имеет встроенный модуль (или легко сделать один) для определенного парсинга.
, Если то, в чем Вы нуждаетесь, многие добавляют (ВСТАВЛЯЕТ?) и последовательное/небольшое количество доступ мало/нет параллелизм, файлы являются способом пойти.
, С другой стороны, когда Ваши требования для параллелизма, непоследовательного чтения/записи, атомарности, атомарных полномочий, Ваши данные будут реляционными по природе и т.д., Вы будете более обеспечены с реляционной базой данных или базой данных OO.
существует много, который может быть выполнен с SQLite3, который чрезвычайно легок (менее чем 300 КБ), ACID, совместимый, записанный в C/C++ и очень повсеместный (если он уже не включен в Ваш язык программирования - например, Python - существует, конечно, одно доступное). Это может быть полезно даже на файлах дб целый 1 ГБ, возможный больше.
, Если бы Ваши требования, где больше, даже не было бы обсуждения, идут для полноценного RDBMS.
В программном обеспечении мне может обычно сходить с рук хранение значений в конфигурационном XML-файле или в реестре, например, программных возможностях. После того как я должен сохранить объекты, которые я перемещаю в базу данных, потому что оплачиваемая авансом стоимость не то, что плохо по сравнению с долгосрочными эффектами, которые могут предложить отношения и создание отчетов.
Для биоинформатики можно быть интересно на этом: Уничтожение на DB. Парень, который работает над этим, является моим другом и имеет работу над быстрым поиском последовательности подобия, он узнал для создания его собственного двоичного устройства хранения данных лучше, чем использование баз данных в этой точке.
я не знаю определенные детали о его решении, но, вероятно, можно обмениваться одним или двумя ideias отправка по почте парня, даже совместно используя код.
Вы нуждаетесь/хотите в SQL-запросах?
несколько человек, собирающихся хотеть получить доступ к данным?
Ваши реляционные данные?
, Если Вы ответили не на те вопросы, Вам (вероятно), не нужно полное на базе данных.
Во-первых, я рассмотрел бы:
- , Как большое желание база данных первоначально быть: # таблиц, # строк
- , Как быстро это вырастет?
- данные, часто запрашиваемые?
, Если я должен был создать персональное приложение рецепта, например, я знаю, что мог бы добавить 50 любимых рецептов, чтобы запустить и добавить не больше, чем 5 рецептов в год. Так как это был сказан, я мог легко продвинуться без базы данных, так как размер хранилища данных окажет минимальное влияние на запросы.
Тем не менее я, вероятно, использовал бы базу данных для любого приложения, где ввод данных и запросы происходят (даже маленькое персональное приложение рецепта). Я не думаю, что это добавляет много издержек особенно, когда Ваша платформа (например, Направляющие) позволяет Вам сохранять свою базу данных немой (прежде всего, таблицы, индексы и ограничения). Это облегчает шанс, что я должен буду в конечном счете портировать на базу данных, если я решаю увеличиться.
Если Вы будете знать формат своих данных, то плоские файлы, если более быстрый/легче для разработки с, будут прекрасны. Если бы Вы ожидаете, что Ваши форматы записи изменятся часто во время разработки затем, я предположил бы, что ALTER TABLE является Вашим другом. Плоские файлы будут также иметь тенденцию быть быстрее (если Вы будете заботиться о скорости), если Вы не ожидаете реализовывать эквивалент соединений через многие комбинации файлов.
реальная выгода использования RDBMS во время разработки является гибкостью, с которой можно изменить схему данных и простоту, с которой можно получить доступ данным через запросы.
Хороший дизайн гарантирует, чтобы Вы сохранили свой уровень доступа к данным относительно изолированным (из-за разделения проблем), таким образом, это должно быть довольно простое (если утомительный), имеют значение для переделки к базе данных, позже должен это стоить. Или, конечно, при использовании базы данных для разработки структур, можно впоследствии забрать приложение в плоские/индексируемые файлы, после того как те структуры кристаллизованы для получения производительности.
Используйте любую технологию персистентности, которой Вы являетесь самыми довольными, и масштабируется достаточно.
YAGNI, по крайней мере, означает, "Не добавляет новая технология к Вашему персональному стеку, если Вы не можете быть продуктивными с тем, что уже там".
Для многих (большинство?) нас нашей зоной комфорта для персистентности данных является SQL. Для некоторых это мог бы быть XML. Просто не пишите свое собственное до (см. абзац 2).
Как кто-то также проводящий исследование в области Биоинформатики, я предложил бы не использовать базу данных для этих видов опытных проектов, если Вы не уверены, что ей нужен он. Если Вы находитесь на заборе, пойдите с решением без базы данных и придерживайтесь плоских файлов. Также важно отметить, что традиционно исследователи Bioinformatics имеют, идут путем плоского файла, что означает, что существуют четко определенные форматы файлов для большинства типов данных в поле. Если Вы решаете пойти с решением для базы данных, оно может повредить Вашу совместимость с существующими исследовательскими проектами.
Есть статья, размещенная на CodeProject , которая может сделать именно это плюс его командной строки на основе.
Надеюсь, это поможет.
-121--1391371-Лично я бы избегал статических методов, поскольку это значительно усложнит проверку этого кода. При тестировании кода, который его использует, вы не сможете легко выдумать DAL. Обратите внимание, что это не уникально для уровней LINQ или доступа к данным, это просто функция кода, являющегося классовым методом, а не методом экземпляра.
-121--4293783- Для тех приложений, которые вы разрабатываете в биоинформатике, вы часто выполняете одноразовые приложения (часто сценарии, которые определяют рабочий процесс вычислений), которые отвечают на конкретные вопросы, и вы вряд ли будете повторно использовать эти приложения после ответа на ваш вопрос.
Часто поэтому следует избегать создания баз данных для хранения результатов, так как в конце концов вы не собираетесь использовать их функции очень много.
Вероятно, вы будете запрашивать некоторые веб-службы, файлы или базы данных, запускать некоторые локальные алгоритмы для данных, собранных из различных источников, и создавать некоторые табличные или структурированные выходные форматы (xml, json и т.д.).
Для этого я предлагаю использовать инструменты workflow-процесса, такие как Knime (или коммерческое решение, такое как Inforsense KDE , Pipeline pilot от Accelrys или Snaplogic , поскольку они позволяют запрашивать данные в различных форматах и местоположениях (rdbms, плоские файлы, веб-службы), запускать алгоритмы и создавать мощные веб-приложения, которые позволяют легко публиковать рабочие процессы пользователям и позволять им взаимодействовать в определенных точках).
Если ваш прототип «растет», и вам приходится создавать больше функциональных возможностей поверх данных, выводимых вашими рабочими процессами, и если выход вашего прототипа вряд ли будет меняться каждый день, то это разумное решение сохранить подмножество результатов в базе данных. Это позволяет подключать мощные средства создания отчетов, такие, как SunObjects, Crystal reports, jasper reports или любое другое доступное решение для создания отчетов, и показывать пользователям данные в лучшей форме, чем электронная таблица или csv-файл.
Наконец, некоторые рамки разработки сделают ваш выбор более очевидным: если вы создадите веб-приложение с использованием инфраструктуры MVC, вероятно, что ваши данные будут находиться в RDBMS (но, пожалуйста, не помещайте геномные последовательности в столбец таблицы: -)).
В целом, это индивидуальный выбор в зависимости от ваших потребностей для каждого конкретного приложения.