Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
2 tygra & pavel Чтобы не разжигать флейма и остановить других авторов: Все это - действительно полная ахинея 2 vic123 Я сам не ожидал, что твоя идея окажется столь плодотворной 2 tygra Sorry, я правда не ожидал :( Удачного отпуска (ты вроде собирался). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2003, 12:53 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
You all shoud know 3 basic principles of modern IT 1) Nothing free. 2) No Magic. 3) Nothing new. And one recomendation USE THE RIGHT TOOL. Look on you arguments from this point of view and you understand what you waste you time for nothing. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2003, 12:54 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
а может ребята у кого-то руки кривые (без обид) а не фокс плохой... не справляется со сложными матрасчетами - а откуда такие в бухгалтерии... или вы пишете расчеты траекторий атомов на фоксе или дельфи??? так для этого кажись фортран есть... продолжим? Продолжим. С чего вы взяли, что кроме бухгалтерии других задач нет? С чего вы взяли, что Delphi не годится для "расчетов траекторий атомов"? фокс ОТЛИЧНО справляется с огромным количеством задач И с огромным не справляется! И еще повторю - тем, кто начинает программировать, нужно начинать именно с SQL серверов и ниже не опускаться. Тысячу раз согласен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2003, 12:55 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
Как красиво все начиналось. Посоветовали мужику СУБД. НЕТ СЛОВ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2003, 13:03 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
>>И еще повторю - тем, кто начинает программировать, нужно начинать >>именно с SQL серверов и ниже не опускаться. >Тысячу раз согласен. Тысячу раз несогласен. Программирование и SQL сервера вещу разные. Начинаеш программировать, начинай. Возьми хоть классический с++, хоть академический фортран, хоть модный ныне перл. А вот если хочеш занятся разработкой реляционных баз, тогда да, sql сервер(практически любой) рулит. Потому как модульность. Нефиг все в одну кучу лепить. одни лучше поиск по бинарным деревьям делают, другие кнопки на формы лепят :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2003, 13:06 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
2 karly В SQL2000 полно глюков, за разгребанием которых вы проведете остаток жизни. Можно хотя бы парочку для примера? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2003, 14:36 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
2 SergSuper Читай мой пост в 12:53 вверху этой страницы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2003, 15:24 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
Хорошо, когда еще есть возможность выбирать. Когда много наработано, переходить на другую систему никто не решится, ты становишся ее заложником... Любую базу нужно писать как Клиент-Серверную. Никто не мешает ее использовать как локальную. Хотя бы MSDE вариант SQL сервера. А в будующем ее можно будет развивать, она будет допускать увеличение нагрузки. Если думаете, что это вам не надо-ошибаетесь. Если задача НУ СОВСЕМ примитивная тогда остается Access, т.к. в нем автоматизировано решение многих типичных и рутинных задач. Вполне приличную форму для ввода/отчет можно создать за несколько секунд. Если для клиент-серверной может быть много вариантов, то для локальной выбор очевиден-Access. А FoxPro только для тех, кто хочет найти себе проблемы. Оно навязывает извращенный стиль программирования и все там делается по уродски. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2003, 16:52 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
А FoxPro только для тех, кто хочет найти себе проблемы. Оно навязывает извращенный стиль программирования и все там делается по уродски Опять это словоблудие. Подкрепляйте пожалуйста ваши слова конкретными примерами. Это какой-то такой уродский стиль программирования оно навязывает? Если вы имеете ввиду использование динамического кода, то кто сказал что это извращенный стиль программирования? В том же C# , который, кстати меня очень радует в плане языковых конструкций, также допускает, с ограниченияеми правда , использование динамического кода. В фоксе это организованно не системно типа захотел выполнить динамически чтото execscript или & и вперед, но тот же SQLServer также это позволяет(со своими уродскими ограничениями , пораждующие вечные вопросы как вернуть оттуда резалтсет) Или может вас раздражает некая вседозволенность - отсутствие контроля типов, открытые члены классов по умолчанию? Да есть такое, но если программист хочет , может все это и самостоятельно отслеживать Фокс не без недостатков конечно, но по-моему вы просто не умеете пользоваться данным инструментом. Ну сколько уже можно об этом говорить... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2003, 17:23 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
2tygra Ты сам то понял, что сказал? Все-равно, что сравнивать какой-нибудь Фольксваген 80 и 2000 года выпуска и орать, что последний круче Когда руки не из задницы растут, тогда все хорошо получается. Тут сами же свою систему пишем, и теперь некоторые места написали бы уже по-другому, а ты про совершенно другую версию. Ты еще сравни SQL Server 6.5 и 2000 Короче, вывод: Те, кто пытается доказать, что dbf это круто, совсем нихрена не понимают. Остальные согласны с тем, что новые технологии есть новые технологии, они есть и их нужно использовать А ты-то понял что сказал? Вот не хотел ввязываться, млин. Да мне плевать на чем там кто пишет. При чем здесь "dbf это круто"? Это ж клиент к Oracle на фоксе был прикручен. DBF там если и есть, так тока на стороне клиента таблицу настройки параметров интерфейса держать. Повторюсь в тонкости не посвящен. Не моя это проблема. Но и обсераловка тотальная мне не нравится. Иди и сделай полезняшку на чем хочешь. И люди к тебе потянутся, млин. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2003, 20:41 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
Я новенький в форуме. Так что все что я скажу имеет полность субьекивную основу, а по сему не надо высказываний об уме, кривых или не кривых ручках в мою сторону :) Кратенько: Я программер в фирме в которой довольно большая сеть магазинов и супермаркетов, как по городу так и по области, причем как от ларьков до средних супермаркетов, везде учет продаж ведется через комп(ы), а также развитый аппарат менеджеров и бухгалтеров, у меня один системщик для магазинов, и два для оффиса. Итак вопрос(не требует ответа): Что предлагают любители клиент-серверных технологий, точнее не любтели fox :), для работы на магазинах с полным нуль администрированием, (при открытии магазина только устанавливаются компы, и запускается установщик который делает ярлыки, и копирует бинарники). это все должен делать один системщик, без особых знаний, очень интересно, кстати у нас все лицензионное , а ворос о стоимости софта стоит очень резко. Ну а вороса в обратную сторону у меня фактически и нет, тут кто то из любителей fox говорил что вобщемто и не предлагает fox для больших баз. Отсутствие каких либо встроенных средств автоматических бакапов, репликаций, адиминистрированния доступа пользователей, да и средств анализа данных, а также проблемы с нагрузками на сеть, индексами, висячими сторками, да и отсутствие юникода туда же, не может не препятствовать использованию таких баз данных в оффисных базах данных. Так что если вопрос еще стоит то dbf еще не умер !!, просто прежде чем что то сделать надо подумать, а потом на всякий случай еще раз подумать над тем что думал :) На счет локальных если всетаки встанет вопрос о таковой то тут однозначно dbf, при всех его недостатках это всетаки стандарт де факто, его потдерживает MS Office, OpenOffice/StarOffice, 1C, для Делфи есть компоненты не используюющие BDE, ODBC в стандартных установках даже Win98 (про Win95 не знаю), а вот Access или Paradox так вопросы вопервых по версиям ну и с подднержкой у них туговато. Вот это груз, сам удевляюсь, в жизне доволно не разговорчив... :) Кстати у вас не у кого конкретных примеров нет, хотя у меня тоже.. но я и о конкретных вещах то не говорил :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2003, 14:47 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
ctmike 1. Если есть лицензия на какой-нибудь продукт Office, то значит есть лицензия на MSDE. 2. Нет непреодолимых проблем сделать инсталлятор 3. Для большинства задач какого-то постоянного администрирования человеком не требуется. Можно все настроить джобами. 4. Насчет сетевых - однозначно НЕ DBF. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2003, 16:35 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
Cat2 Лицензия на Office 2k стоит 200 $ это не выход к томуже, если например у меня на магазине сервер Net 2003 то у меня еще и проблема к инсталятору лепить и сервис пак, итак что получается, мой инсталятор должен установить mssql, sp3(можно sp2, так как в третьем я не нашел ничего что меня смогло заитерисовать, кроме потдержки Net 2003), далее скнфигурировать базу (к своему стыду я не знаю как это сделать програмно, буду рад услышать мнения:)), запустить скрипт создания базы данных, а дальше уже запустить свою программу. Честно.., меня это почемуто не вдохновляет. Если использовать mysql то тут с установкой меньше проблем, да SAB DB тоже как будто просто правда в последнем релизе они что то намутили с инсталяцией. Но это все головняки. Которые осутствуюют при использовании тогоже dbf :) Кстати благодаря ODBC переход от dbf к mssql вообще труда не составит, а вот наоборот, это проблема века, как не хочеш а stored procedures , functions, views это все таки круто. Так что вопрос вообще сводится нравятся или не нравится технология ODBC ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2003, 19:16 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
P.S. Я прочитал и только потом дошло у меня не создание базы данных вызывает проблему, а настройка параметров атозагрузки, использование памяти и т.д. И еще меня резонно можно перенаправить к документации, но это не мерьезно так все это изменяется разными утилитками, в разных местах (в лучшем понимании этого выражения :)), вобщем то все то что можно сделать за небольшой промежуток времени в том же Enterprise Managere Извените что не сразу нашел свою ошибку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2003, 19:22 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
to ctmike: если у вас АРМы исключительно специализированные, то используйте Linux и FireBird как SQLсервер. Они оба free =) это что касается лицензий. По поводу Win-платформ: тот же Firebird/Yaffil как SQL-сервер. Локальный или выделенный роли не играет. Либо если есть лицензии на MS Office и данных немного или они регулярно (раз в день например) передаются в центральный офис - MDB как хранилище. Или MSDE. Но он более тяжелый, хотя для нульадминистрирования можно настроить unattended setup. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2003, 21:36 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
Denis A. Я сенгодня походил по сайтам посмотрел что говорят про Firebird/Yaffil вобщемто мне не понравилось, большинство мнений что на текущий момент они стабильней чем InterBase, но InterBase развиваются (v7.1), а вот остальные пока что не особо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2003, 22:49 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
ctmike У меня в двух конторах стоит Yaffil на win9x! Работает (3 и 5 клиентов соответственно - update/insert/select ~ как 1/3/10). Уже два года. Работает. Что я делаю не так? =) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2003, 20:45 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
Denis A. Извини я не хотел обидить тебя в лучших чувствах, просто мне инетересно в будущем они будут развиваться или нет, это был просто вопрос, я вообще вобщемто опредилился с набором баз данных и пока меня ни кто в этои переубедить не сможет :) Еще раз, это дискусия, и я спросил как относится здешнее людство к слухам о возможной кончине Firebird/Yaffil ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2003, 21:51 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
Да вот насчет локалньной базы кто то про 1C напомнил со всеми их DBF'ами. Хочу вставить свои 2 копейки. Про то что типа большие объемы данных можно лопатить, дак вот нельзя НЕЛЬЗЯ_НЕЛЬЗЯ_И_ЕЩЕ_РАЗ НЕЛЬЗЯ. Система состоит из 3 человек которые просто вколачивали данные (платежки, квитанции, накладные), стоял отдельный сервер, сетка 100 м/б, клиентские компы все пни3 1000 Мгц, памяти у них немеряно. дак вот эти три человека так нагружили сервер что он время от времени просто падал, потом база херачилась приходилось востанавливать с бубном. А если там бы сидели не три а 20-50 человек, что за сервер там нужен был бы и сетка гигабитная не меньше. Вообщем для тех кто работал на 1C (хотя и не исключаю вероятность кривости рук писателей 1C, тем не менее есть куча примеров где все это тряхомудие показало себя в полной "Красоте") это прекрасный привер DBF-ов, и фокса, как бы там слюнями не раскидывались поклонники Фокса это прошлое, которое стоит побыстрее забыть, и не забивать им себе голову. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2003, 11:35 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
to 1 А у нас на предприятии с 1С одновременно работало 10 человек, плюс всякие дополнительные прилады, загрузка-выгрузка данных, и т.д. И работало нормально. А потом 1С проапгрейдили до SQL-версии, купили новый сервер под это дело. И все стало жутко тормозить :( И что? Думаешь, это основание для заявлений типа "SQL отстой, dbf rulezzz" ? В успехе первого варианта, в проблемах второго, да в твоем случае причина одна - настройки сервера и сети. И искать решения проблемы лучше в соответствующих конференциях, а не делать далеко идущих выводов про "отсталость формата dbf" или "достоинства VFP как языка программирования" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2003, 12:17 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
>>И еще повторю - тем, кто начинает программировать, нужно начинать >>именно с SQL серверов и ниже не опускаться. >Тысячу раз согласен. Тысячу раз несогласен. Программирование и SQL сервера вещу разные. Пожалуйста, читайте внимательнее. Речь шла о программировании приложений БД. Поэтому ваше возражение не соответствует контексту. Извини я не хотел обидить тебя в лучших чувствах, просто мне инетересно в будущем они будут развиваться или нет Еще раз, это дискусия, и я спросил как относится здешнее людство к слухам о возможной кончине Firebird/Yaffil Дело в том, что на реальных БД довольно трудно баловаться с версиями:-(. К примеру мы до сих пор используем MSSQL6.5 и только планируем переход на 2000й. С IB/FB/YA, конечно попроще, но все равно любая смена версии - лишняя головная боль. Так, что ставьте FB и не волнуйтесь. На ваш век хватит. Тем паче, что кончины не предвидится. А вот переход на коммерческие версии вполне возможен:-(. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2003, 16:04 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
Я работаю с Fox уже лет 10. В основном, правда, с ДОС 2.6. Не знаю, как насчет виндовых версий, но в досовых во всех есть проблемы с нештатным прерыванием работы. Тот кто этого не видел - просто мало работал с ним (и с юзерами). При правильном проектировании файл-серверная архитектура не очень мешает. Конечно для задач с разумным пределом объема данных и потребностями пользователей соотв. возможностям Fox. Тем, кто утверждает, что Fox медленно работает под нагрузкой могу сказать только одно : exec Исправить('Руки разработчика'); У нас работает на FPD 2.6 корпоративная самописка : постоянно интенсивно работают 10 юзеров, периодически запускают отчеты - 50. База - 120 Мб. (только данные). При отчетности обрабатывается согласно фильтрам пользователя (преимущественно вся). Самый сложный отчет - где пользователем настраивается каждая строка отдельно, на 10 страниц объемом, считается за 1 мин на сети 100М, клиент PIV-2400. Все остальное - от 5 до 40 сек на Celeron'ах, P-II,P-III. Задача - финансово-бухгалтерского плана. Главная проблема - уж очень теперь сложно real-time OLAP сверху прикрутить :-) Стал смотреть VFP недавно. Уныло! ООП к нему привинчен "сбоку" мягко говоря, библиотеки компонент фиг найдешь и большинство платные, работа с SQL сервером сделана убого. Так что решили больше с VFP не связываться. Delphi, или VB, C# (та же беда с библиотеками) в качестве клиентов MSSQL показались более оптимальными. А с платформой БД - определиться очень просто : (кратенько) Задача небольшая, данных немного (менее гига) или же данные можно разделить на рабочие и архивные, потенциально глобального разрастания проекта не предвидится, частичная потеря данных не слишком критична (можно за день восстановить утраченное без очобых напрягов). Используем Fox, Access, Paradox, в общем файл-сервер. Если нарушается любое из условий (и чем сильнее нарушается, тем более важно!) - используем SQL сервер, ориентированный на соотв. задачу. Ну и конечно, тут же надо учитывать сроки, стоимость, знание инструментов и т.д. В общем, судя по изначальному вопросу - не надо человеку с SQL заморачиваться... Проще надо быть :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2003, 14:34 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
Я работаю с Fox уже лет 10. В основном, правда, с ДОС 2.6. Не знаю, как насчет виндовых версий, но в досовых во всех есть проблемы с нештатным прерыванием работы. Тот кто этого не видел - просто мало работал с ним (и с юзерами). При правильном проектировании файл-серверная архитектура не очень мешает. Конечно для задач с разумным пределом объема данных и потребностями пользователей соотв. возможностям Fox. Тем, кто утверждает, что Fox медленно работает под нагрузкой могу сказать только одно : exec Исправить('Руки разработчика'); У нас работает на FPD 2.6 корпоративная самописка : постоянно интенсивно работают 10 юзеров, периодически запускают отчеты - 50. База - 120 Мб. (только данные). При отчетности обрабатывается согласно фильтрам пользователя (преимущественно вся). Самый сложный отчет - где пользователем настраивается каждая строка отдельно, на 10 страниц объемом, считается за 1 мин на сети 100М, клиент PIV-2400. Все остальное - от 5 до 40 сек на Celeron'ах, P-II,P-III. Задача - финансово-бухгалтерского плана. Главная проблема - уж очень теперь сложно real-time OLAP сверху прикрутить :-) Стал смотреть VFP недавно. Уныло! ООП к нему привинчен "сбоку" мягко говоря, библиотеки компонент фиг найдешь и большинство платные, работа с SQL сервером сделана убого. Так что решили больше с VFP не связываться. Delphi, или VB, C# (та же беда с библиотеками) в качестве клиентов MSSQL показались более оптимальными. А с платформой БД - определиться очень просто : (кратенько) Задача небольшая, данных немного (менее гига) или же данные можно разделить на рабочие и архивные, потенциально глобального разрастания проекта не предвидится, частичная потеря данных не слишком критична (можно за день восстановить утраченное без очобых напрягов). Используем Fox, Access, Paradox, в общем файл-сервер. Если нарушается любое из условий (и чем сильнее нарушается, тем более важно!) - используем SQL сервер, ориентированный на соотв. задачу. Ну и конечно, тут же надо учитывать сроки, стоимость, знание инструментов и т.д. В общем, судя по изначальному вопросу - не надо человеку с SQL заморачиваться... Проще надо быть :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2003, 14:34 |
|
||
|
Выбор локальной СУБД
|
|||
|---|---|---|---|
|
#18+
ООП к нему привинчен "сбоку" мягко говоря, библиотеки компонент фиг найдешь и большинство платные, работа с SQL сервером сделана убого Интересно знать , что конкретно вас не устраивает? Ни флейма ради, просто из любопытства. Вот мое мнение по поводу чего не хватает в ООП в Фоксе. 1) Удобного визуального средства для навигации по классам описсанных в prg(txt). Если VCX(классы хранятся в dbf) более менее все хорошо, то в PRG не очень. Видел какую платную (30 у.е) софтину на этот счет, но особо не заморачивался.Есть еще правда бесплатный ClassNavigator, но он кривовато работает Пользоваться VCX для невизуальных классов совсем не хочется, а стандартный Document View недостаточно удобен,по крайней мере иерархию не показывает. 2) Не очень красиво работает IntelliSence с классами. Все время наровит все сделать маленькими или наоборот большими буквами. 3) По умолчанию все члены класса PUBLIC. Отвыкаешь ставить нужную область видимости и принцип инкапсуляции нарушается 4) Практически отсутствует строгая типизация По поводу работы как клиент вообще непонятно какие могут быть серьезные претензии, так как кроме полной поддержки ODBC есть поддержка ADO и XML, последний причем даже в варианте который создается ADO.NET. Серьезно не хватает только работы с оторванными рекордсетами. Передача рекордсета с клиента на среднее звено, только через XML , либо при полном использовании ADO. Использование чистого ADO правда не очень удобно так как приходится использовать внешние визуальные ActiveX компоненты( Xpress Quantum Grid) например. In Conclusion Наибольшая проблема VFP в его низкой популярности. Есть еще одна правда - этот инструмент требует слишком аккуратно с собой обращаться. Кривоту рук фокс не прощает - чуть , что не так напишешь может появиться Fatal Exception :((( Наверное поэтому его так бояться новички... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2003, 15:21 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=32194346&tid=1554304]: |
0ms |
get settings: |
9ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
65ms |
get tp. blocked users: |
1ms |
| others: | 217ms |
| total: | 361ms |

| 0 / 0 |
