Выбор используемой базы данных
PS Надеюсь, может идею выразел ламерским языком, но в 9 утра по-другому не получается :)
PS Надеюсь, может идею выразел ламерским языком, но в 9 утра по-другому не получается :)
Access самое оно будет
ЗЫ: а можно в 1С конфигурацию свою накидать, тоже как вариант.
А dBASE канает?
Да все нормально, открывается, читается.
если сам access как клиент не нравится, сделать *.mdb файл БД и своего клиента
PS Надеюсь, может идею выразел ламерским языком, но в 9 утра по-другому не получается :)
Во-первых, если работа предполагается изначально многопользовательская (не важно, сколько - главное больше чем один) и вы предполагаете что в дальнейшем вы будете долго сохранять отношения с заказчиком, мой вам хороший совет - никогда не используйте Access,Paradox или FoxPro. Исключение из этого правила - ваш заказчик, воплощение вселенского зла, и вы таким образом пытаетесь ему отомстить и остановить завоевание мира, или же вам необходимо интегрировать вашу разработку в существующий продукт, а реинжиниринг не возможен в связи с временными и денежными сроками. И то второе положение - достаточно сомнительно и легко решается.
Во все остальных случаях - выбор есть и не маленький - начиная от Firebird - очень мощный сервер, со множеством возможностей и бесплатен до MSSQL - тоже существуют бесплатные варианты с возможностью многопользовательской работы.
Во все остальных случаях - выбор есть и не маленький - начиная от Firebird - очень мощный сервер, со множеством возможностей и бесплатен до MSSQL - тоже существуют бесплатные варианты с возможностью многопользовательской работы.
Задам глупый вопрос :) А почему? :) (Сугубо для общего развития объясните, если можно)
Ну если коротко.
Потому что, Access - это инструмент, который предназначен для работы с настольными БД или в качестве клиента - с серверами. Соответственно, во-первых, в нем отсутствует целый ряд инструментов и решений для работы с данными (типа ХП, пользовательских функций и т.д.), во вторых - отсутствуют нормальные механизмы для многопользовательской работы (и реализуются на уровне ОС, а не самой системой - что в принципе не очень хорошо). В третьих - необходимость размещать базы в общем доступе - что естественно снижает безопасность в разы.
Файловые базы данных которым относятся остальные две - уже давно устарели раз, второе - все вышесказанное относится и к ним - два. Поэтому без крайней необходимости, я бы рекомендовал их не использовать.
P.S. Это так, к слову. На постгресе работаю сам год и никаких претензий к нему самому не имею :).
Я так понимаю что для 5 менеджеров из отдела продаж для удобства надо создать некое хранилище фамилий и контактов клиентов.
Если все вышеперечисленные требования по безопастности, скорости и пр. не так важны, то в аксессе такую БД накидать, делов на 1-2часа, причем времени больше уйдет на оформление интерфейса.
На худой конец, мы в свое время, это все вели в общедоступном экселовском файле :D, попросили одмина отрыть доступ к папке где он лежал только 3-м лицам, и усе.
Я так понимаю что для 5 менеджеров из отдела продаж для удобства надо создать некое хранилище фамилий и контактов клиентов.
Если все вышеперечисленные требования по безопастности, скорости и пр. не так важны, то в аксессе такую БД накидать, делов на 1-2часа, причем времени больше уйдет на оформление интерфейса.
На худой конец, мы в свое время, это все вели в общедоступном экселовском файле :D, попросили одмина отрыть доступ к папке где он лежал только 3-м лицам, и усе.
потому что любой проект имеет тенденцию к неконтролируемому росту. и если вменяемая СУБД, при нормальном проектировании структуры базы, без проблем сумеет перенести рост числа менеджеров с 5-и до 10000, то наколенные поделки вроде "баз" в Excel или Access - умрут.
1. Мне вообще это не надо
2. Что разбросано по инету, не факт что "прямое" тем более не свое
3. на изучение чужого можно потратить больше времени чем на составлениие своего, при том что чужие косяки отловить гораздо сложнее чем свои.
вот поэтому у нас такаие требования к программистам, как в том боянистом анекдоте: "Если бы к водителям применялись такиеже требования, как и к прогрммистам..."
Сначало надо ставить задачу, с учетом всех требований, а потом уже думать как ее решать, а не стрелять из пушки по воробъям "м.б. база разрастется"
Сначало надо ставить задачу, с учетом всех требований, а потом уже думать как ее решать, а не стрелять из пушки по воробъям "м.б. база разрастется"
нет. поэтому у нас такие корявые проекты. когда сляпают на скорую руку, "шоп работало", а потом сверху начинают лепить костыли.
тем более, что задача топикстартером была поставлена:
многопользовательская программа, работаюшая с БД.
нормальной альтернативы SQL базе тут нет.
тем более, что задача топикстартером была поставлена:
многопользовательская программа, работаюшая с БД.
нормальной альтернативы SQL базе тут нет.
Я не против того чтоб поставить SQL сервер (под него выбить отдельный сервак), написать для него своего клиента, раздать всем нужные права, вобщем организовать все "как надо", только стоит ли это того? Если пользователей всего 5 по условию и исходя из него в БД будут 1-2 таблицы, да и нагружать БД не думаю что будут 24 часа в сутки.
А на случай разрастания, можно просто клиента толкового написать, который сможет работать и с аксессом и с SQL сервером.
ЗЫ: а проблема вобще выеденного яйца не стоит.
Отдельный сервак при указанных автором условиях не нужен, сервер БД вроде постгреса в таких условиях возьмет несколько десятков мегабайт. Oracle и DB2 --- согласен, побольше.
написать для него своего клиента
Ну можно и не писать своего клиента, а взять готовые клиенты (тот же RazorSQL, например, или хоть pgAdmin3), для работы с данными. Если же потребуется написать своего клиента, то это на нормальной платформе, имеющей средства для работы с БД, можно сделать очень быстро.
раздать всем нужные права, вобщем организовать все "как надо", только стоит ли это того? Если пользователей всего 5 по условию и исходя из него в БД будут 1-2 таблицы, да и нагружать БД не думаю что будут 24 часа в сутки.
А на случай разрастания, можно просто клиента толкового написать, который сможет работать и с аксессом и с SQL сервером.
ЗЫ: а проблема вобще выеденного яйца не стоит.
Имхо, ты преувеличиваешь сложность развертывания SQL-сервера и работы с ним. Я бы в такой ситуации выбрал SQL не раздумывая.
Т.е. важна не сама цель, а процесс.
Так же и здесь получается: на БД, которую писать уже разработанными и проверенными средствами можно потратить максимум день (если вообще не знать ничего), пытаются навешать столько условий, что их реализовывать будешь гораздо дольше, тем более если не знаешь всех вышеперечисленных СУБД.
ЗЫ: знаю что не прав в глобальном смысле (в смысле организации правильной БД), но от своих слов в локальном смысле не откажусь.
ну... я бы склонился к этому серверу не только по этому...
sql-сервер firebird обладаем гораздо более весомыми плюсами, нежели бесплатность.
это и кроссплатформенность, и чрезвычайная мощность, устойчивость, безопасность, удобство, документированность, малое потребление ресурсов и, что немаловажно, легкость изучения. к этому серверу (точнее, к серверу interbase, и, естественно, его клонам firebird и yaffi) написано множество утилит и программ, ускоряющих скорость разработки и отладки конечного приложения.
но выбор, конечно, делать Вам...