Технология хранения данных, какую выбрать?

[SSV]

Какую же все-таки  технологию, хранения данных,  лучше всего использовать?

В принципе выбор не велик: либо текстовые файлы, либо базы данных (SQL). И те и другие по своему удобны и обладают каждая технология, рядом своих преимуществ. К примеру: работа с текстовым файлом, как с базой данных представляет преимущества:

1.   Гибкость. Не зависимо от операционной системы, можно легко создавать и сохранять данные, при этом совсем нет нужды устанавливать, какое-либо дополнительное программное обеспечение, так как эта технология работает не посредственно  с файловой системой, любой ОС.

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

3.   Экономия дискового пространства и скорость работы. Так как принцип, создаваемой базы данных, на прямую зависит от программиста, то размер её данных, сильно зависит от структуры, созданной базы данных. Но, так как это текстовый файл, то он в любом случае, всегда будет занимать меньше дискового пространства. В свою очередь, обращения на прямую, как файловой системе, минуя программы обработки программного обеспечения, значительно ускоряют доступ к данным.
В свою очередь работа с базами данных, такими как «MySQL» имеет свой ряд преимуществ.

1.   Безопасность.  Базы данных (SQL), как правило, лучше защищены, чем в простых файлах, от внешнего вторжения, не считая того, что они защищены на уровне операционной системы.

2.   Сложность структуры. Так как в базах данных (SQL), можно хранить данные, с очень  сложной структурой и взаимосвязями, то это во многом упрощает поиск и извлечения  требуемой информации и.

3.   Многопользовательский режим. Так как программное обеспечение автоматизирует весь процесс, по обращению, как базе данных (SQL), то не приходится беспокоиться о том, что может произойти не согласование, при обращении, в многопользовательском режиме, и не произойдёт случайного затирания данных.

Если у кого есть какие-то дополнения или критики – высказывайте. Также прошу поделиться опытом по работе, с  указанными выше базами данных.
Мой выбор: первый вариант. В принципе зашифровав текст, с алгоритмом, который сам придумал, представляет уровень защиты не хуже, чем в SQL, хотя он (алгоритм) может быть  достаточно прост, но преимущества такого подхода, в том, что только программист знает алгоритм. Сложность структуры, так же не представляет больших проблем, равно как и многопользовательский режим, тоже вполне разрешимая задача.

Прошу ваши мнения…

[Ray]

Не думаю,что текстовые файлы - хорошая идея.
С MySQL не работал,но в ближайшее время собираюсь.

Как ты в текстовом файле уместишь много полей различных типов,их ведь еще как-то разместить надо?
По-моему это бред.
Сам подумай.Тебе придется писать какой-то парсер для этой базы.С учетом того,что позиционирование будет не ахти,а оно таким я будет,будут сложности с парсингом этой базы.А как с ней работать через,например,PHP ? Я думаю - это будет очередная проблема.
В наше время с дисковым пространством проблема не возникнет.
По поводу скорости работы сильно сомневаюсь,что ручная реализации переплюнет уже устоявшуюся MySQL.
Своя шифровка данных эт тоже не то.
Реализовать ее можно,но...
Свой алгоритм придумывать не надо,можно просто синтезировать,нпример,алгоритм RSA с каким-либо еще.
Я думаю это плохая идея с базой в текстовом файле.
Лучше воспользуйся MySQL.

[SSV]

Большое спасибо – Ray!

Ваше мнение очень интересное, хотя и мало аргументированное. К примеру: неимения идей по поводу реализации структур, это не значит, что реализовать эти структуры сложно, и PHP, тут не исключение. На счёт дискового пространства вы правы, проблем нет, но это решать поставщикам услуг хостов. Скажем если хост 100мб, то очень резко возникают проблемы с дисковым пространством, то есть с квотой, которую вы оплачиваете. А на счёт скорости вы не правы, в этом и состоит главный плюс такого подхода. Скорость выигрывается за счёт того, что не нужно прибегать к услугам программного обеспечения, реализующего такой сервис. А как я упоминал выше, этот способ работает не посредственно с файловой системой.

Я совсем не критикую метод работы, с базами данных SQL. Мне очень интересно мнение публики.

С уважением – Сергей.

[Ray]

Есть такая фраза:
"Идея конечно хорошая,но реализация - говно"
Это я к тому,что сделать-то структуры в текстовом файле можно,но как это будет работать?
Понимаешь,возникнут проблемы с разбором этого файла.
Да и с защитой такой базы будут проблемы.
Как ты будешь обращаться к текстовому файлу на винте через PHP?
Ты ведь еще учти,что скорее всего к этой ббазе в текстовом файле будет обращаться большое количество людей.Да еще у каждого свои права доступа ддолжны быть.

[SSV]

Извиняюсь –Ray, но если вы считаете, что у меня кривые руки, это я на счёт реализации, хотя обо мне, ни чего не знаете, старайтесь его публично не высказывать. Чтобы не вводить других в заблуждение.

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

Какие проблемы с защитой, мне не понятно, я же изложил выше, что можно прибегнуть, к шифрованию. На счёт шифрования RSA, скажу, что это очень медленный алгоритм, к примеру, 3750 байт/с; при скорости  процессора 2Гц и ключом в 512 бит.

А по поводу работы с бинарными файлами, если вы этого не знаете, хотя странно, как не зная этой концепции вы со мной дискутируете... Юзайте www.php.net/faq.php, раздел "работа с  файлами".

А вообще, хотелось бы слышать веские аргументы, по поводу критики лично в мой адрес.

Скорость работы, в этом случае неоспорима. Доступ к данным на много быстрее, чем через SQL.

Единственное с чем я соглашусь, в вашу пользу, хотя я и ранее этого не отрицал, то это простота обращения к данным, их поиск и извлечение. В этом случае, не нужно беспокоиться о шифровании, не нужно знать структуры, самой базы данных. Сделали запрос - получили ответ. Программные средства, в этом случае, сделаны, для упрощения работы программисту, но не как альтернатива. А внутри работает по тому же принципу, которого сторонник я.

Прошу простить меня, за излишнюю дерзость в ваш адрес.

[Ray]

Про кривые руки я не говорил.
И это не в твой адрес было сказано.Просто фраза такая есть,эт я так,к сведению.
Просто не было сказано,что данный метод уже применялся на практике.
Раз уж применялся и прекрасно работает,то прошу прощения,если как-то обидел.
Но простота работы,я думаю,иногда все-таки лучше,чем лишние "телодвижения"

[SSV]

Нет проблем, я не обиделся. На то она и дискуссия... :ad:
В любом случае - благодарю, за высказанное мнение.

[spyplane]

Если с какогото перепугу БД Mysql не доступна, хотя не понимаю такой ситуации  :ai:
то можно через xml базу делать - оч хороший вариант, правда производительность и ресурсы... но для небольший протянет

[Ray]

Согласен со spyplane.Вполне может подойти использование xml.

[SSV]

Перепуг, к примеру такой - только FTP доступ к хосту.
На счёт xml - спорно...

[spyplane]

Перепуг, к примеру такой - только FTP доступ к хосту.
На счёт xml - спорно...

т.е. есть кусочек с пхп и на другом серваке бошое место по ftp?
Ну не правдоподобно, но возможно, допустим...
А вот xml почему не нравится? Медленно, да, но пошустрее текста и структуру понимает

[SSV]

Я, вполне согласин с Вами - spyplane, что как альтернатива xml-подходит. Но скорее всего для второй категории. Хотя сами расссудите, использовать xml, когда есть такой инструмент как SQL - просто бонально.

[spyplane]

Я, вполне согласин с Вами - spyplane, что как альтернатива xml-подходит. Но скорее всего для второй категории. Хотя сами расссудите, использовать xml, когда есть такой инструмент как SQL - просто бонально.

Дык в условиях задачи у нас нет SQL, вот и ищем что-то подобное, а если есть возможность юзать sql - тогда ясно что делать  :ab: