logo
logo

Форум Standard database

создать новую тему раскрыть все
Standard database xFlower 14/02/2006 23:18 #написать ответ
Глупый, наверно, вопрос.
А почему бы не пользоваться для хранения данных готовыми субд?
Это убивает сразу огромную кучу зайцев:
- не надо писать свою базу (отлаживать, сопровождать...)
- встроенные в субд средства безопасности
- встроенные в субд средства резервного копирования, защиты от сбоев и т. п.
- практически готовый гейт куда угодно, хоть в тот же excel - написал запрос и понеслась.
- когда вдруг появится решение перейти на другую платформу - это тоже будет сделать легче
наверняка ещё что-то есть.
какие субд вы предлагаете для... космический рэйнджер 15/02/2006 10:00 #написать ответ
использования, а чувак?
 
чё-та я те скажу, шо твоя идея попахивает большым гимароем для меня, пользавателя!!
 
вах, какой атлы
А какую именно? Dmitriy 15/02/2006 11:06 #написать ответ
Для бесплатной программы очевидно подойдут только бесплатные СУБД. Какую именно Вы хотите предложить?
 
Да и к тому же переход на универсальную СУБД в корне поменяет идеологию программы. Размер дистрибутива будет огромным, скорость работы упадет, требования к аппаратным ресурсам возрастут... А смысл? Пока не вижу серьезных проблем с резервным копированием, безопасностью и сбоями.  
Только не надо голословности Дим(м) 15/02/2006 11:56 #написать ответ
Чем вам, например, SQLite не "стандартная СУБД"?
Насколько я понимаю, все, что нужно AbilityCash, там есть (и даже больше, на будущее
А "огромный" в отношении SQLite означает 150К.
http://www.sqlite.org/
 
Честно говоря, я и сам уже подумывал предложить использовать именно готовую СУБД. Останавливало меня только опасение, что с этим переходом нового билда опять придется ждать полгода..
 
В общем, сейчас я действительно не вижу смысла что-то менять в плане СУБД. А как вариант "на будущее" ссылку на SQLite приберег бы.
Идея -- блеск! Андрей 15/02/2006 13:33 #написать ответ
Я всегда знал, что наступит тот день, когда БД станет узким местом. И с ужасом думал про BDE..... Ну, обычно все (когда вдруг нада база) его юзают..... А здесь -- sqlite -- все типтоп! Идея мне кажется рациональной, как и сам АбилитиКэш.
ага. xFlower 15/02/2006 17:43 #написать ответ
BDE юзают, если исходно всё написано на дельфях.
А так вариантов много, смотря на чём пишем.
Тот же MSDE, на крайняк. Места, правда, занимает как слон, зато бесплатно и поддерживается.
Главное в этом деле не закладываться на хранимые процедуры, что привяже софтину к одной базе.
RE: И с ужасом думал про BDE Explorer 18/02/2006 16:05 #написать ответ
Borland Database Engine is dead - смотрите в сторону Absolute Database
ОК! Спасибо за инфу. (-) Андрей 19/02/2006 15:20 #написать ответ
вопрос kilo 15/02/2006 14:12 #написать ответ
так или иначе поднимался. И все то, что вы перечислили, каждый из нас уже делал - в базе, которая называется Microsoft Excel. Каждый мудрил свои способы/методики учета, функции, интерфейсы, и т.д.
И большинство так или иначе "прискакало" к конкретным программам (и не только к Кэш).
Причина, как мне кажется, в том, что часто требуется просто маленький перочинный ножичек, чтобы аккуратно выполнить одну конкретную задачку. И не более.
Для домашнего (индивидуального) учета именно это представляет Кэш :- экзешник, ини-файл и довольно компактная, сжатая, защиенная база.
 
Предлагая использовать готовые субд вы выхолащиваете саму идею Кэш, на что автор, конечно, не пойдет.
Перочинный ножик с 100000 записей Андрей 15/02/2006 14:34 #написать ответ
А как будет работать Кэш при 100000 записей?
Меня Кэш устраивает практически полностью Он решает поставленные мной задачи. Сейчас, при 7000 записей. Да, скроллинг тормозит жутко, но итоги считаются-пересчитываются на лету. Но что будет при 100000 записей??? Дервишь, может ты делал пробную базу с тестовыми записями под 100000 штук? Как она работала при этом?
PS у меня у четверых человек база по 7000 записей, если бы мы вели одну -- 28000 записей. Как она при этом работала бы?
PPS пень3-мобайл-1133-512-geforce2go
Это очень легко проверить. (+) Dervish 17/02/2006 16:17 #написать ответ
Все четыре базы данных ваших сотрудников выгружаются в Excel, а потом четыре excel-евских файла импортируются в одну базу данных. После этого смотрите результат.
 
Есть небольшая разница в импорте операций в Cash (1.3, 1.4) и в AbilityCash. Cash импортирует всё подряд, не задумываясь. AbilityCash проверяет, если аналогичная операция уже существует (совпадают дата, время, суммы, классификаторы), то дубликат не импортируется. Но, думаю, что средствами Excel-я можно довольно просто откорректировать даты (время) перед каждой загрузкой и тогда вы легко можете попробовать и базы данных на 100 тысяч операций.
 
И Cash и AbilityCash разрабатывались так, чтобы вся база данных для работы загружалась в оперативную память. Расчёт строился на то, что скорость роста оперативной памяти компьютеров гораздо выше, чем скорость роста данных. Это даёт плюс в скорости расчётов, но минус в ограничении размера данных. Но, если есть интерес в этом, просто попробуйте, никто не запрещает.
 
И напоследок маленький вопрос:
 
<font color=black>&gt; Да, скроллинг тормозит жутко, но итоги считаются...
 
Если можно, поподробнее: какая версия программы (Cash/Abilitycash)? Какой скроллинг тормозит? В каком месте?
 
Вы напрасно говорите об этом между делом. Я стараюсь сделать так, чтобы ничего не тормозило, но могу пропустить отдельные моменты. Нужно на них указывать.
 
Спасибо.
Ответы Андрей 17/02/2006 22:56 #написать ответ
1. По поводу размеров базы беру обязательство создать базу на 1 млн. записей и проверить работоспособность.
2. Тормоза проявляются так: при переключении с любой вкладки (счета, агенты, и т.д.) на вкладку "операции" шапка окна перерисовывается моментально, а вот сам список операций появляется только через 1,5 сек. Это первое. Второе, устанавливаем курсор на любую операцию и колесиком мышки скролим, получаем такую картинку http://splaising.com/image/ac-ss.jpg. Операция "Парикмахерская" существует в единственном числе, а здесь она расплылась, пройдет секунда-другая и экран полностью перерисуется, все будет ОК! Когда надо часто туда-сюда бегать по списку, это раздражает. Вопрос размера базы поднялся у меня именно из-за такого поведения, внутри чувство неуверенности, что 20 тыс.операция она не потянет вообще, т.е. считать будет быстро, но вводить и корректировать информацию будет невозможно.
PS ноутбук dell инспирон пень3-мобайл-1133мгерц, рам512, экран 15 1600х1200, geforce2go.
Забыл указать: АбилитиКэш билд205 (-) Андрей 17/02/2006 23:17 #написать ответ
Миллион записей, это... Dervish 22/02/2006 15:01 #написать ответ
...круто. Но, боюсь, вряд ли это будет нормально работать: Кеш проектировался для работы с относительно небольшим количеством данных поскольку он их все всегда целиком грузит в оперативную память. Нельзя объять необъятного и если ваша база слишком велика, то будьте добры посмотреть в сторону больших, "промышленных" баз данных. SQL Server или Oracle, ну, в общем, под задачу подбирать нужно.
 
А вот тормоза при прорисовке никак не могут быть связаны с несчастными 7 тысячами операций. 7 тысяч это очень немного. Тут нужно разбираться более детально. Есть у меня одно подозрение, но оно требует проверки.
 
Спасибо.
Я создал базу+ Андрей 22/02/2006 16:28 #написать ответ
на ок.30000 записей через импорт из экселя (размер файла ок. 4,5 метров). В опер.памяти база заняла ок. 50 метров и столько же в вирт.памяти (размер файла 4,5 метра). Работала весьма живенько. Даже поразился! И только вот фильтр по датам работал секунд 30-40... Все мат.расчеты производились мгновенно. Задержка в прорисовке как была 1,5 сек., так и осталось. Дублирование прорисовки как было, так и осталось. Таким образом, я сделал вывод, что при достаточности ОЗУ база может быть очень большой, она не течет, но фильтрация данных потребует повышенной производительности ЦПУ.
Результатом остался очень доволен.
Хочу ещё добавить, что... Dervish 22/02/2006 17:02 #написать ответ
...все данные размещаются в памяти в допущении, что количество данных растёт гораздо медленнее, чем доступные объёмы памяти. В общем, к тому моменту, когда у вас соберётся данных на 50 мегабайт файла, оперативная память уже будет исчисляться как минимум десятками а то и сотнями гигабайт. Закон Мура пока выполняется.
 
Теперь о существующих задержках.
 
1. Задержка в прорисовке. В общем, полторы секунды превышает комфортное время реакции системы, так что тут нужно разбираться. Обязательно постараюсь это сделать.
 
2. Фильтр по датам. Я посмотрел на ваш скриншот и, если я правильно понял, вы выводите в список операции вообще все операции. Думаю, что если ограничить количество выводимых операций, например, поставив фильтр по датам на текущий месяц или квартал, то и фильтр и прорисовка будут выполняться гораздо быстрее.
 
Вообще я рекомендовал бы выбрать в периоде текущий квартал, и активнее пользоваться фильтром счетов. В этом случае программа вообще не должна тормозить и должна работать очень быстро. Скажем, мой компьютер гораздо менне мощный чем ваш (P-III, 750MHz, 512MB Ram, 1024x728 Neomagic) а объёмы данных чуть больше ваших. Но никаких тормозов я не наблюдаю. Совсем. Всё работает очень быстро.
 
Попробуйте, мне было бы интересно узнать отзыв, как изменилось быстродействие.
 
Спасибо.
Спасибо за внимание к проблеме + Андрей 22/02/2006 19:40 #написать ответ
1. Да, такая прорисовка некомфортна. Если вы ее исправите, буду очень признателен.
2. Да, там выведены все операции. При фильтре по датам в том случае задержек не было. Задержки в 30-40 секунд относятся к тестововй базе на ок.30000 записей при фильтрации всех записей фильтром "дата". Безусловно, если ограничить временной интервал скажем за месяц, то горадо быстрее.
PS создал базу на 65518 записей и не могу ее импортировать. Читает, пытается записать, появляется на месте диалога белое окно, загрузка ЦПУ АКэшем 96%, прошло 64 минуты и я его вырубил... Позднее попробую еще раз.
А можете мне прислать... Dervish 23/02/2006 15:00 #написать ответ
...xsl-файл на 65518 записей? Виснуть не должна полюбому, мне интересно посмотреть что же там такое...
Да, файл xls могу выслать.+ Андрей 23/02/2006 16:47 #написать ответ
Да, файл xls могу выслать, но чуть позднее: надо личные данные откорректировать
А получил я его экспортом своей базы, а потом копировал операции и вставлял, меняя при этом бюджетную дату, так догнал до 65518 (больше 65536 строк excel мне не дал строк .
PS На выходных попробую еще раз импортировать.
Андрей, ну так как насчёт... Dervish 01/03/2006 21:01 #написать ответ
..."выслать файл"?
 
А про строки...
 
Можно в одну базу импортировать несколько разных файлов Excel-я. Так что ограничение в 64К строк обходится довольно просто.
Выслал на мыло (-) (-) Андрей 03/03/2006 14:16 #написать ответ
Совершенно согласен xFlower 15/02/2006 17:50 #написать ответ
&gt; компактная, сжатая, защиенная база.  
Ну ещё можно добавить "надёжная и быстрая".
 
Это собственно то, что бригада программистов пишет в течение нескольких лет.
Кстати, access для этой цели подошёл бы, может быть, даже и лучше, чем екцель. Но они оба стоят денег.
И у меня к этому "перочинному ножику" есть одно очень важное требование: если завтра автора переедет трамвай, а база откажется поддерживать больше N записей я не желаю потерять все свои данные.
 
Кстати.
Компактность, например, мне совершенно не принципиальна.
Занимает база мегабайт или десять - мне пофиг. А вот если я к ней могу составить любой хитровы...нный запрос (а то и вааще, написать для жены специально web-форму, чтобы она в неё могла чеки вбивать) - это большой плюс.
Опять же. Мне банк присылает выписку в формате eprst. Мне бы её сверить бы с тем, что у меня есть - тоже приятно было бы.
Маленькое замечение по базам Андрей 15/02/2006 18:13 #написать ответ
Мне все равно сколько весит база -- 1 метр или 10 метров -- только в том случае, если это <B>один</B> файл, а не директория с сотней файлов.
PS да, я понимаю, что отдельная таблица = отдельный файл. Так быстро и правильно, масштабируемо и безопасно. Но для "домашней" программы это недостаток, имхо.
PPS ну, на 6 файлов (счета, операции, статьи, агенты, проекты, валюты) я согласен, если база будет держать свободно 1 млн.записей.
PPS также я против установки отдельно всяких СУБД, типа BDE, Первасиве и т.п.
? ash 18/02/2006 19:58 #написать ответ
&gt; да, я понимаю, что отдельная таблица = отдельный файл.  
&gt; Так быстро и правильно, масштабируемо и безопасно
&gt;  
/* не желая поднимать лишний шум из ничего */
простите, может я что-то упустил, но из чего следует данное утверждение?  
по-моему, ваше предложение - лишь один из возможных способов организации БД.
Так, это из теории баз :) Андрей 19/02/2006 15:26 #написать ответ
Простейший пример - телефонно-адресный справочник. Фио - один файл, улицы - другой, и т.д. Общий размер базы уменьшается, но нагрузка на проц увеличивается по сравнению с плейн-текстом, где размер базы большой, а нагрузка на проц меньшая.
Но с вами, по поводу ваше предложение - лишь один из возможных способов организации БД согласен полностью.
Андрей, мне представляется, что... Dervish 22/02/2006 15:04 #написать ответ
...многофайловые базы просто неудобны для пользователя в поддержке. Если всякий раз при переносе данных нужно будет пересчитывать количество переписанных файлов, лично меня это будет раздражать. Поэтому база данных Cash и AbilityCash всегда будет как один, единый файл. Только из соображений удобства. Ничего личного.
:) Андрей 22/02/2006 16:13 #написать ответ
Согласен -- один файл -- это удобно! Но если вдруг надо будет делать базу из шести файлов, то будем все это размещать в отделном каталоге -- имхо, это ведь не проблема! Кроме как перед шифрованием pgp надо будет архивировать каталог. А под <B>много</B>файловыми базами я понимал базы с 50-2000 файлами, когда совершенно не ясно, какой файл что именно содержит.
PS 1C7.7 (моя база данных) состоит из 300 *.dbf
с ума сойти! :) ash 25/02/2006 09:54 #написать ответ
&gt; PS 1C7.7 (моя база данных) состоит из 300 *.dbf
&gt;
О боже, какой кошмар!
Пофиг xFlower 24/02/2006 19:30 #написать ответ
Каталог - тоже файл.
Только толстый
 
А в любом случае вместе с базой ещё захочется перенести настройки.
Это уже два файла.
А если есть отдельная база у кошки и отдельная у собаки - уже три.
 
Тогда, получается, вообще, надо делать кнопку "упаковать базу" и "распаковать базу".
А тогда ещё сама просится ежедневная автоупаковка в архив.
Интересный вы вопрос подняли (+). Dervish 17/02/2006 15:43 #написать ответ
Попробую ответить всем, чьи сообщения я прочитал чуть выше.
 
Самая-самая первая версия Cash (она никогда не публиковалась) была сделана на базе Access. И была почти сразу же переделана. Access на практике оказался очень тормознутым. Впрочем, думаю, что Америку я открыл только для себя, спецы об этом уже всё давно знают, для меня же это был первый опыт использования Access.
 
Кроме того, у Access-а были очень серьёзные проблемы с установкой. Те пользователи, которые не устанавливали себе MS Office получали жуткие проблемы со скачкой среды Access. MS даёт возможность скачать с сайта только библиотеки Access-a, что, собственно и нужно для работы, но трафик там немеряный.
 
В общем, Access ни в какие ворота. BDE, извините, мне тоже не понравилось именно из-за того, что её нужно устанавливать дополнительно. Да и "заточено" BDE под продукты Borland, которыми я не пользуюсь.
 
В общем, на момент начала работ я не смог найти базу данных которая бы удовлетворяла вот таким требованиям: (а) компактность, (б) скорость работы, (в) маленький размер и, наконец (г) бесплатность. SQLite я просто не заметил, не попалась она мне на глаза.
 
Возможно, что если бы попалась, всё было бы по другому, потому как эта база действительно достойно реализована. Мне понравилась.
Я хочу чуть-чуть добавить xFlower 18/02/2006 00:27 #написать ответ
Есть ещё один тонкий момент, который, правда, возможно, в России пока не принципиален.
Access денег стоит.
(Равно, впрочем, как и excel)
 
Да, и в связи с этим по поводу excelя.
Возможно, действительно, имеет смысл сделать экспорт или в XML или (простите моё занудство) в SQL.
В SQL в смысле создать файл из строк типа INSERT INTO blah-blah...
 
Или, может быть, что-нибудь типа CSV...  
Я ни на что не претендую, но, например, у меня дома нет MS-офиса. А какой-нибудь экспорт данных иметь хочется.
 
Re: Standard database Dervish 17/02/2006 15:56 #написать ответ
Ну а теперь о проблемах нынешнего дня.
 
<font color=black>&gt; - не надо писать свою базу (отлаживать, сопровождать...)
 
Уже написано. Отлажено. Программа всё равно должна сопровождаться, так что особых проблем с сопровождением не вижу.
 
<font color=black>&gt; - встроенные в субд средства безопасности
 
Скорее всего встроенные средства пользователей не устроят. Большая категория пользователей настаивает на том, что база должна очень серьёзно шифроваться. Стандартные же базы как правило не шифруют свои данные а следовательно взламываются очень просто.
 
<font color=black>&gt; - встроенные в субд средства резервного копирования, защиты от сбоев и т.п.
 
Опыт показывает, что надёжность системы зависит не от наличия средств резервного копирования, а, скорее, от того, включит ли эти средства пользователь. Так что не думаю, что стандартные базы в чём-то тут имеют преимущество.
 
<font color=black>&gt; - практически готовый гейт куда угодно, хоть в тот же excel - написал запрос и понеслась.
 
Ну гейт в Excel есть и сейчас. Согласитесь, это закрывает практически всё что нужно. Ну для эстетов ещё можно сделать обмен с xml.
 
<font color=black>&gt; - когда вдруг появится решение перейти на другую платформу - это тоже будет сделать легче наверняка ещё что-то есть.
 
Вы сами-то верите в переход на другую платформу? Но даже если верите... Скажу по секрету, что самое трудное в переносе AbilityCash на другую платформу будет не в переносе базы данных... А в работе с экранной средой. База данных, это файловые операции, перенос которых реализуется обычными обёрточками над стандартными вызовами. А вот экранная среда может иметь совсем другую идеологию, так что там так просто не получится.
 
И ещё одно: один мой знакомый постоянно пользуется AbilityCash под Linux в среде wine. Прекрасно всё работает. А если иногда случаются зависимые от платформы сложности у него, я стараюсь исправлять проблемы.
 
В общем, AbilityCash совместима с Linux/Wine, хоть это нигде официально и не заявлялось.
всё уже придумано до нас? ash 18/02/2006 20:02 #написать ответ
&gt; самое трудное в переносе ... работа с экранной средой.  
&gt; экранная среда может иметь совсем другую идеологию
&gt;  
/* ни коим образом не желаю бросаться своим уставом в чужой огород */
 
Но ведь есть вполне работоспособные решения:
1. java
2. qt
с ними - никакая платформа не является помехой.
всё уже придумано до нас? andpal 20/02/2006 17:01 #написать ответ
Все-таки сумничал
У автора свой стиль, свои предпочтения и цели.
Многоплатформенность для него (и многих других) видимо не актуальна.
Мне все пока очень нравится.
... ash 25/02/2006 10:01 #написать ответ
&gt; Все-таки сумничал   
&gt;  
На всякий случай, вдруг кто не в курсе
 
&gt; У автора свой стиль, свои предпочтения и цели.
&gt;  
Разве из моего сообщения следовало, что я каким-либо образом покушался на свободу мыслеизлияния автора в коде приложения?
Я так понимаю, xFlower 21/02/2006 18:15 #написать ответ
это версия 3.0. Возможно. Не раньше.
Конечно! (+) Dervish 22/02/2006 15:11 #написать ответ
Просто задача переноса не ставилась в начале разработки. Да и, честно говоря, я и сейчас смысла в этом не очень вижу, так, просто зашёл разговор...
 
Попутно повторю, что какая-никакая, но совместимость с Линуксом есть. Программа нормально работает в среде Wine (по отзывам - сам не пробовал). Ну вот просто такой побочный эффект.
 
В общем, не думаю, что задача кроссплатформенности стоит очень остро.
БД Dmitriy 02/06/2008 06:06 #написать ответ
&gt; Скорее всего встроенные средства пользователей не устроят. Большая категория пользователей настаивает на том, что база должна очень серьёзно шифроваться. Стандартные же базы как правило не шифруют свои данные а следовательно взламываются очень просто.
 
Не всегда так.
К примеру тот же SQlite шифрует БД.
В стандартной базе данных... Dervish 17/02/2006 16:04 #написать ответ
...я вижу только одно преимущество: это одновременный доступ к данным по локальной сети. Сейчас программа работает только в монопольном доступе к данным. Делать же одновременный доступ мне очень не хочется, так как это очень трудная задача, связанная с синхронизацией потоков на разных машинах.
 
Так что появление AbilityCash Network Version я таки исключать не буду, хотя, понятно, что быстро это не случится.
А я вижу еще одно преимущество Loki 20/02/2006 13:55 #написать ответ
Используюя стандартный sql появляется возможность написанию любых плагинов и отчетов. Так как знают данный язык многие, база представляет собой обычный текстовый файл (это я про sqllite). Так что это тоже можно занести в актив. Правда, функционально sqllite несколько урезан, но над этим работают... хотя, толку от их работы...
одновременный доступ andpal 20/02/2006 17:08 #написать ответ
Прошу, не надо!!!
Получается прекрасный персональный менеджер финансов!
Ему не нужен, даже вреден, разделяемый доступ.
А проблем с самостоятельной его реализацией действительно очень много.
Тогда на самом деле логично взять "стандартную" СУБД, но еще раз прошу,
продолжай делать что делаешь.
Я понимаю, что это... Dervish 22/02/2006 15:14 #написать ответ
...будет уже совсем другая программа. Если будет.