В чем вести БД?
 

Подскажите, в чем лучше вести базу данных?
Имеется некий каталог запчастей.
В базе должны содержаться запчасти и узлы ... так скажем каждая деталь может лежать в разных узлах, а узлы лежат также в узлах ... и т.п.

Нужна некая программа для работы с БД (например MS Access) чтобы можно было посадить людей и они набивали эту базу. Желательно с возможностью совместной работы. И чтобы интерфейс был простым.

Важное условие, потом все данные необходимо будет экспортировать в некий файл, а-ля xml, чтобы уже в РНР можно было его раскидать в базу на сайте.

Вот и хотел бы спросить совета, какую СУБД лучше использовать? (желательно бесплатную)

Любую, какую программист лучше знает. Тут главное не выбор СУБД, а создание интерфейса для вбивающих людей. Нужно сделать такой интерфейс, чтобы им было как можно меньше работы (тогда сделается всё быстрее) и они допускали как можно меньше ошибок (тогда меньше переделывать потом, и сделается всё быстрее). А какая СУБД будет это вообще не важно, хоть в текстовый файл пиши.

А базу нужно дин раз набить? Или регулярно заполнять свежей инфой?

Вообще распространённая ошибка у программистов -- они не о том думают. Сначала они думают, какую взять СУБД, потом, какие таблицы сделать, потом, какие поля в этих таблицах. А потом уже делают поля ввода для каждого поля в таблице, заполняй мол, мил человек. В результате такой программой пользоваться невозможно, и программиста все ненавидят. Хотя нет, ненавидят программу, ассоциация с программистом почему-то редко проходит.

Рассуждать же нужно с другой стороны: а какое самое удобное поведение для ввода данной информации в компьютер? Для этого нужно знать, что и в каком виде имеется сейчас, и что должно иметься потом. А на данном этапе универсальных советов я ещё не придумал :)

Я склоняюсь к MS Access, вроде там создать нужный интерфейс несложно. И наверно совместная работа возможна и т.д. Вот только в каком виде мне потом от туда в РНР скрипт перегнать данные?

К примеру: есть программа "???FOX" она работает с базами в *.dbf. Да и потом эти файлы можно напрямую в РНР открыть, вот только неудобная она.

А из MS Access потом как данные выдернуть, есть у кого-нибудь опыт?

ну, если верить гуглу, то ничего сложного в этом нету
личного опыта работы нету

Да забейте Вы париться!
 

Накропайте формочек (хоть на том же PHP). Пусть пишут хоть в форматированный файл - главное, чтобы набивальщикам было удобно.

Потом - ещё простенький скриптец, который файлы даДЁнные ему попарсит и в БД закинет. Это если БД ещё не готова на момент начала "набиватики". А по-хорошему так сразу в базу покидать прямо из формочек.

Все-же остановлюсь на Access, там вроде всё очень легко накидать можно...

greatilya,
О, да, я с этой MSAccess навозился.

ODBC так с LAMP подружить и не удалось. В итоге сошлись на том, что из Access брался файл экспорта в XML, а оттуда уже пихался на сайт, сначала в MySQL, а позднее в PostgreSQL.

XML на сервере разбирается крайне шустро — около 5 секунд на разбор 110 Мб, для каталога запчастей типа той же «амаямы» хватит с головой.

subzey,
можете дать советы по импорту в XML.. ну или ссылочки и т.п. )

Буду очень признателен...

Подразумевается PHP.

Есть класс DOMDocument, которые позволяет разбирать XML как DOM. Самое вкусное — XPath, но можно работать и с такими известными методами и свойствами, как getElementsByTagName, parentNode, childNodes и многие другие.

Подробнее, как всегда, в мануалах: http://ru2.php.net/manual/en/class.domdocument.php

Маленький пример:

<export>
	<item name="Мясо" price="105.95" available="1"></item>
	<item name="Рыба" price="47.95" available="1"></item>
	<item name="Молоко" price="37.95" available="0"></item>
</export>

$document = new DOMDocument();
$document->load("export.xml");
$xpath = new DOMXPath($document);
foreach ($xpath->query("/*/item[@available=1]") as $node){
echo $node->getAttribute("name") . ": " . $node->getAttribute("price") . " руб.<br />";
}

subzey,
Огромное спасибо за описание! (я обычно пользовался SimpleXML)
А из access в XML как перегоняли, стандартными средствами (Файл -> Экспорт -> тип файлов xml)?

Мне нужны две разные бд, чтобы я потом из одной бд в другую бд перегонял. Звучит как глупая хохма.

Берется стандартная MySQL и ставится к ней интерфейс (CMS), здесь выбор очень большой. Затем набивальщицы набивают, а администратор делает дамп и пихает на сайт.

greatilya,
Вы придумали себе проблему и пытаетесь её решить, невзирая на то, что проблемы такой нет.

Оп-п-п-па
так разве можно?коллекции перебирать-то?
на досуге проверю.
я просто всегда делал через $elems->length И $elems->item($i)

Gozar,
Опять вы с критикой.
Поясню более подробно.
Сейчас имеется действующий сайт на котором более 200 000 запчастей. И в силу того что на сайте стоит CMS NetCat и реляционные связи в таблицах не такие простые, управлять эти сайтом средствами CMS стало неудобно. Тем более что необходим стабильный доступ в интернет, при том что забивка каталога занимает очень много времени. Я хоть и старался сделать систему более удобной, выжал максимум из NetCat, добавил Ajax и т.п. Но управлять всё-равно тяжеловато.

Вот и было решение сделать локальный интерфейс для забивки БД с последующим экспортом на сайт. Думаю средствами Access получится сделать более удобный интерфейс.

Можно было бы конечно подключаться из некого локального интерфейса к БД на сайте, но от этого потеряется скорость.

greatilya,
Может быть локальную копию базы держать на внутреннем серваке? Тогда проблем с доступом через инет и скоростью не будет. А удобный интерфейс к ней, я уверен, Вы напишете?

Мне не нужно пояснять более подробно, если вы выбрали плохо продуманную CMS, это ещё не значит что БД плохая. Смените CMS или напишите свой интерфейс.

Вы по всей вероятности этого просто не можете или вам за это не заплатят?

Вы в данном случае не БД обсуждаете, а интерфейс к ней. На том уровне что вы указали умеют работать ВСЕ существующие БД. 200 000 это смешно.

CMS продуманная
он там есть, причем выжимал по максимуму. Для пользователя выбор нужной детали был проблематичным. Вероятно вы правы, что легче придумать, написать интерфейс.
Со всем уважением к вам, задача там далеко не тривиальная...
Попробую придумать отдельный интерфейс средствами веба...

Gvozd,
ага. Там итератор определен.

предел удобства универсального решения (CMS, MS Access) при условиях стремящимся к благоприятным, равен удобству специализированного решения

а в чем конкретно сложности?

autocomplete проблему не решает?

В принципе если сделать его по двум полям (код и наименование) то думаю будет несколько проще.
Я же там делал ввод нескольких символов кода, а потом нажимается "Найти" и высвечивается список деталей, после чего необходимо щелкнуть щелкнуть по нужной строке.

Как я и думал клиенты все-же выбрали Access. Им понравилась идея заполнения каталога в в локальной сети без подключения к сети Интернет.

У вас Бред.

Пользователи выбрали то, что в отсутствии предложенного им выбора они могли выбрать. Вы делаете такие же необоснованные выводы как и люди, которые считали что земля плоская и стоит на трех китах.

Фактически вы не ищите лучшее решение, а оправдываете свою некомпетентность в этом вопросе за счет не понимающих в этом ничего пользователей. Надеюсь никто из начинающих программистов не примет ваши домыслы за правильное решение.

Разве только Access, способен это делать?

зы:
Решение проблемы с интернетом: Ставиться локальная версия сайта.
Решение проблемы с интерфейсом: Дописывается интерфейс.

Если интерфейс тяжело или невозможно дописать, выбирается другой интерфейс, бд при этом менять не обязательно.

Только по явному требованию пользователей, когда они говорят мы хотим вести бд в Access, т.к. ни в чем больше не умеем и не хотим или у них уже есть бд в Access, придется использовать Access.

Gozar,
вот, Вы не поверите. Некоторым людям действительно архиудобны MS Access и 1С. Особенно это актуально для 40-летних манагеров, которые просто не хотят переучиваться. Как писал Алан Купер, «когнитивное сопротивление»

Я же написал придется - значит верю.

нет. Но Access более доступен.
Вы думаете клиентам так легко будет в своей локальной сети поставить Apache? С апачем придется дольше возиться, нежели Office стоит на всех ПК.
Работа в СУБД под Windows куда быстрее, т.к. соединение с сервером БД происходит на большей скорости, нежели это было бы средствами Internet.
Вы напоминаете мою дочь, она тоже не имея информации может строить выводы. Только правильность этих выводов под большим вопросом.
Клиент независимо от меня тоже перебирал различные СУБД и варианты. Только я это делал взглядом программиста, а он системного администратора.
Приемущества Access:
- не требуется подключения к интернету
- быстрая реализация нужного интерфейса в конструкторе (полезно, когда нет времени писать/придумывать интерфейс под веб-браузер)
- возможность импорта из Excel (бывает полезно)
- интерфейс можно менять, в отличие от многих других СУБД

Ну вы конечно сравнили:
MS Access - система которая постоянно обновляется и старается следить за новшествами в БД, и старается включить в себя множество стандартов,
и
1С - система которая была написана видимо только для разработчиков 1С ... т.к. это настолько узкая и "дебильная" система ( (с) знакомый 1с программист ), что об удобной работе с ней можно забыть...

Я считаю MS Access достаточно неплохим продуктом, в виду его удобности. Вот я с ним толком не работал, зато вчера за час - два практически накидал нужный интерфейс.

Gozar,
моё мнение, что вы несколько зацикливаетесь на вебовских языках и стандартах. В мире сделано много чего хорошего и полезного. Ключевой же момент, который я преследовал, это - удобство работы пользователям, их пожелания и предпочтения.

Gozar,
конечно спасибо за критику в мой адрес, но мне она показалась не обоснованной...

У меня вся инфа на сайте в access-ах хранится. Пока проблем не было.

Вот и я о том же, главное - удобство для пользователя.

Как связана СУБД с удобством для пользователя? Как? С СУБД общается с программой, человек общается с программой. С какой СУБД общается программа человеку всё равно. Причём здесь удобство пользователя? Скорость разработки -- возможно, но не удобство пользователя.

Kolyaj,
+1, по крайней мере, так должно быть ;-?

Много компаний сидят под ubuntu и Aceess им как шило в зад. Не путайте теплое с пушистым.

Откуда мне знать что у вас нет сисадмина, и да я думаю легче поставить Apache. Office, будьте поточнее потому, что в ОpenOffice есть подключение к MySQL, удаленной, локальной, без разницы.
поэтому следующее выражение бессмысленно:
Вы напоминаете мне мою кошку, она тоже мало видела жизнь и не знает о существовании собак или мышей, однако это не обозначает что их не существует.

В следующей цитате просто замените слово Access на OpenOffice базы данных. Свое имя я заменил на ваше. Правда странно?

А MS Access уже не однопользовательская?

занимался раньше 1С но бросил т.к. не нашел по ней работы. Но тем не менее узкой и "дебильной" она мне не показалась. Скорее четкой и продуманной. ;) Для документооборота - самое оно. (с 8-й версией не знаком, но там еще все лучше наверное)

Может это он об интерфейсе к БД - заполнении данных, изменении структуры(добавление полей...). Давно с Access не работал но помню что там это как раз на уровне сделано - обычным людям интуитивно понятно(гридики с подсказками автоинкремента, значений по умолчанию ...). Если с mysql, клиенту phpmyadmin тоже не предложишь, нужно писать интерфейс самому под базочку чего ТС и хочет избежать.

а Access как поможет? Может дело в том, что пользователи не любят веб-интерфейсы? Я вот, например, не люблю Access, хотя давно им не пользовался или даже можно сказать, что я им толком никогда не пользовался. Так, запускал когда-то, чтобы посмотреть. Так что я не очень в теме. Но программа, которая предлагает пользователям самим создавать свое приложение... я считаю у программиста, использующего решения предназначенные для программистов, получится лучше

и да, для более предметного разговора, стоит рассказать, что именно неудобно пользователям

Пользователи не любят плохие интерфейсы, а веб они или не веб -- не важно.

читать не умеем?

Gozar, а что еще в ОpenOffice есть для работы с MySQL кроме подключения?

micscr,
слабо самому посмотреть?

посмотрел, кое что есть и неплохое, но все же скорее для специалиста, а не для рядового пользователя.

Gozar,
спасибо.

greatilya, если поразбираешся в связке OpenOffice+MySql, отпиши пожалуйста о результатах. Забавная вещь, может где то пригодиться.