> К тому же даже если "своё" будет кишить дырами, 90% из дыр > можно будет списать со счетов, т. к. никто все равно не > знает, как именно моя база работает. Вот это, кстати, опасное заблуждение. Поскольку любой мало-мальски знающий свое дело взломщик в состоянии догадаться, какие дырки могут присутствовать даже в незнакомой программе. Банальные переполнения буфера можно находить, не имея никаких сведений, кроме интерфейса "для всех". Точно также как и некоторые injection'ы.
Может ли кто-нибудь аргументированно указать плюсы/минусы использования текстовиков/баз данных в качестве хранилища?
Мне часто предъявляют, что я лох, тк использую текстовики, а не базы, но я ещё так не испытал особой нужды в переходе на вторые.
Да и вообще, используя текстовики, я знаю что, где и как устроено, и уверен что не допущу ошибку, которая повлечёт за собой серьёзные последствия..
может хватит флейма? тема уже исчерпала себя, имх13.07.04 11:17 Автор: !mm <Ivan Ch.> Статус: Elderman
Значит таких нужд не было.. База данных - это высоконадежный...08.07.04 22:27 Автор: ne_budu_pozority_tut_nik Статус: Незарегистрированный пользователь
> Может ли кто-нибудь аргументированно указать плюсы/минусы > использования текстовиков/баз данных в качестве хранилища? > > Мне часто предъявляют, что я лох, тк использую текстовики, > а не базы, но я ещё так не испытал особой нужды в переходе > на вторые. > Да и вообще, используя текстовики, я знаю что, где и как > устроено, и уверен что не допущу ошибку, которая повлечёт > за собой серьёзные последствия..
Значит таких нужд не было.. База данных - это высоконадежный продукт, обладающий высокой продуктивностью и выполняющий сложные математические и логические задачи.
Я программирую на PHP, как-то хотел написать игру. Но перед этим я перечитал документацию mySQL-А, И случайно увидел почти математические и символьные функции, которыми я пользуюсь в программироваии..
Базы данных в интернете кроме надежности могут давать еще и безопасность. При умелом использованиии можно значительно понизить риск взламываемости сайтов... Но сегодня навряд-ли найлуца люди, когторые выставляют для отдельных таблиц - различные права доступа...
Может это и правельно.. Безопасность настолько высокая не нужна... Не Пентагон мы все-таки...
Для частных случаев написание своей собственный базы...09.07.04 00:39 Автор: Heller <Heller> Статус: Elderman
> Значит таких нужд не было.. База данных - это > высоконадежный продукт, обладающий высокой продуктивностью > и выполняющий сложные математические и логические задачи.
Для частных случаев написание своей собственный базы построенной на файлах даже более эффективно в плане производительности. то уже обсуждалось, почитай топик.
> Я программирую на PHP, как-то хотел написать игру. Но перед > этим я перечитал документацию mySQL-А, И случайно увидел > почти математические и символьные функции, которыми я > пользуюсь в программироваии..
И чего? =)
> Базы данных в интернете кроме надежности могут давать еще и > безопасность. При умелом использованиии можно значительно > понизить риск взламываемости сайтов... Но сегодня > навряд-ли найлуца люди, когторые выставляют для отдельных > таблиц - различные права доступа...
Не понятно.. По-подобрей пожалйста про этот пункт.. не догоняю..
> Может это и правельно.. Безопасность настолько высокая не > нужна... Не Пентагон мы все-таки...
Угу.. Вот только взлом базы - первый шаг к захвату сервера. А дальше можно слать СПАМ, к примеру. И разбирайся потом с РОСНИИРОС. Не надо никогда недооценивать безопастность. Хотя бы когда в этот форум пишешь :-)
ЗЫ. А грамотно писать на русском языке, значит, не обязательно?
Может при работе 2-3х файлов скорость работы и быстрее.. Но...09.07.04 19:24 Автор: ne_budu_pozority_tut_nik Статус: Незарегистрированный пользователь
> > Значит таких нужд не было.. База данных - это > > высоконадежный продукт, обладающий высокой > продуктивностью > > и выполняющий сложные математические и логические > задачи. > > Для частных случаев написание своей собственный базы > построенной на файлах даже более эффективно в плане > производительности. то уже обсуждалось, почитай топик.
Может при работе 2-3х файлов скорость работы и быстрее.. Но при разработке больших проектов сталкиваешься с полным хасом огромных баз данных (таблиц).
Именно для правильной связи таблиц и логически обоснованной работы с целью сохранять целостность баз данны и были разработаны SQL, ORACLE.
Можно предположить, что при неудачной записи в файл данных - файл будет поврежден, и при большом количестве данных только этот факт вызовет катастрофу. Хочу посмотреть , как такой файл будете чинить..
Есть еще такой фактор, что при огромном количестве информации mySQL, ORACLE будут работать с коэфициентом выше чем с файлами..
Вообще, что я скажу ребята... @#$ней вы страдаете....
Я как-то брал в руки огромный томик теории баз данных - это вам не цацки пеци... Это теоретически и практически обоснованная огромная работа по работе с базами денных, где скорость, безопасность и безотказность - главные принципы работы.
> > > Я программирую на PHP, как-то хотел написать игру. Но > перед > > этим я перечитал документацию mySQL-А, И случайно > увидел > > почти математические и символьные функции, которыми я > > пользуюсь в программироваии.. > > И чего? =)
А того, что это не конь с яйцами и таблицами... А продукт в котором количество возможностей настолько широко, что никто из вас, включая мну не представляем...
> > > > Базы данных в интернете кроме надежности могут давать > еще и > > безопасность. При умелом использованиии можно > значительно > > понизить риск взламываемости сайтов... Но сегодня > > навряд-ли найлуца люди, когторые выставляют для > отдельных > > таблиц - различные права доступа... > > Не понятно.. По-подобрей пожалйста про этот пункт.. не > догоняю..
Не только программно можно ограничивать действия при работе с mySQL но и условиями доступов. Например "прозрачный" скрипт , который имеет доступ к БД , ломаемый сегодня имея ту или иную уязвимость - содержит ключик к БД. Имя ключик (данные доступа к серверу) видишь всю информацию..
Но скажем для таблицы кредитных кард в БД можно дать доступ только на запись... И имея только второй (непросматриваемый в скриптах) код к БД можно увидеть эти данные.
> > > > Может это и правельно.. Безопасность настолько высокая > не > > нужна... Не Пентагон мы все-таки... > > Угу.. Вот только взлом базы - первый шаг к захвату сервера. > А дальше можно слать СПАМ, к примеру. И разбирайся потом с > РОСНИИРОС. Не надо никогда недооценивать безопастность. > Хотя бы когда в этот форум пишешь :-)
Можно и наоборот сказать. Взлом сервера - первый шаг к захвату БД ;)
А взломанных сайтов могу достать кучу.. Да толку ? Ты спаммер ?
> > ЗЫ. А грамотно писать на русском языке, значит, не > обязательно?
Я вроде не Пушкин...
Алексей
========
[CETb]
Небольшое уточнение07.07.04 16:11 Автор: Heller <Heller> Статус: Elderman
Возможно, кого-то повторю, но вроде это ещё не упоминалось.
Если использовать в качестве базы файлы, то тогда уж не файлЫ а только ОДИН (или несколько) файлов. Ведь например в FAT32 размер кластера 32КБ - если файл отведён к примеру под топик в форуме, то это уже будут колоссальные потери. Как в других ФС будет, я не знаю, но в любом случае физический размер кластера просто обязан быть.
А по фигу07.07.04 16:38 Автор: amirul <Serge> Статус: The Elderman
> Возможно, кого-то повторю, но вроде это ещё не упоминалось. > > Если использовать в качестве базы файлы, то тогда уж не > файлЫ а только ОДИН (или несколько) файлов. Ведь например в > FAT32 размер кластера 32КБ - если файл отведён к примеру > под топик в форуме, то это уже будут колоссальные потери. У меня NTFS отформатирован (по умолчанию) с 8 секторов/кластер. То бишь 4096. Даже с таким форумом как bugtraq (уже почти 110 тыщ сообщений) это 450 метров. Любой современный винт выдержит это без малейших проблем. А если учесть еще и удаленные топики (один Urix чего стоил :-) ), то все вообще замечательно.
> Как в других ФС будет, я не знаю, но в любом случае > физический размер кластера просто обязан быть. Проблема ФС в другом. Они не рассчитаны на работу с десятками/сотнями тысяч файлов в каталоге. И даже по ключевому полю - имени - поиск при таких масштабах будет весьма небыстрым.
Да иногда не по фигу07.07.04 18:42 Автор: Heller <Heller> Статус: Elderman
Хых.. Ну это по фигу если ты сидишь на собственном серваке. А если сервер виртуальный, где каждый мег оплачивается? У меня хостинг, например, так там вообще всего 300mb выделяют.
ЗЫ. А поиск по файловый системе, как уже рассматривали, оптимизируется. Хотя случаются и геморрои.
Ну в случае с виртуальным хостингом как мне кажется дисковое место будет не самым узким местом08.07.04 12:15 Автор: amirul <Serge> Статус: The Elderman
> Хых.. Ну это по фигу если ты сидишь на собственном серваке. > А если сервер виртуальный, где каждый мег оплачивается? У > меня хостинг, например, так там вообще всего 300mb > выделяют. Производительность базы будет в любом случае выше. А ведь на виртуальных хостингах борятся чуть ли не за миллисекунды.
> ЗЫ. А поиск по файловый системе, как уже рассматривали, > оптимизируется. Хотя случаются и геморрои. Постоянная переиндексация при добавлении сообщения это ли не геморрой :-)
Хотя я не уверен, что NTFS переидексирует каталог полностью (а не добавляет новинки в индекс), но мне все еще не дают покоя рекомендации по УВЕЛИЧЕНИЮ производительности путем отключения индексирования. Если есть такие рекомендации, значит с индексированием у NTFS что то не так.
Чаще всего это выражается в запрещении установки чатов и...09.07.04 17:09 Автор: Heller <Heller> Статус: Elderman
> Производительность базы будет в любом случае выше. А ведь > на виртуальных хостингах борятся чуть ли не за > миллисекунды.
Чаще всего это выражается в запрещении установки чатов и баннерных ротаторов - на то как именно ты что реализуешь мало кто смотрит.
> Постоянная переиндексация при добавлении сообщения это ли > не геморрой :-)
Тут в голову возможное решение заглянуло :-) Можно разбивать всю файловую базу на несколько каталогов в каждом из которых будет лежать небольшая часть файлов. Тогда регулярную переиндексацию можно и пережить - не такие будут потери. Можно вообще организовать два каталога - один со старыми постами (в случае форума), а другой с новыми - при накоплении в последнем достаточного количества файлов перекидывать их в каталог со старыми данными и переиндексировать соответственно. Имхо, вполне эффективное решение.
Ага09.07.04 17:57 Автор: amirul <Serge> Статус: The Elderman
> Чаще всего это выражается в запрещении установки чатов и > баннерных ротаторов - на то как именно ты что реализуешь > мало кто смотрит. Вот только, если ты превысишь квоту - писать тебе потом в саппорт хостера с вопросами о том, за что вырубили сайт.
> переиндексировать соответственно. Имхо, вполне эффективное > решение. Ага. "А нельзя сразу БАЦ?" (с) Мартышка
Вы действительно считаете, что такая система ПРОЩЕ, чем БД?
Да не.. Наверное я не так выразился.. Я имел ввиду не...09.07.04 18:28 Автор: Heller <Heller> Статус: Elderman
> Вот только, если ты превысишь квоту - писать тебе потом в > саппорт хостера с вопросами о том, за что вырубили сайт.
Да не.. Наверное я не так выразился.. Я имел ввиду не реализацию чатов и ротаторов, а именно реализацию баз. В общем не понятен ответ.
> Вы действительно считаете, что такая система ПРОЩЕ, чем БД?
Может быть и не проще, но гораздо понятнее. К тому же указанный способ я приводил для того только случая, когда есть неоходимость в переиндексации и её нельзя отключить. В общем случае применение приведённого метода не требуется (на практике я думаю сделать разбивку на каталоги - максимум строчек десять кода - ничего сложного и хитрого в алгоритме нет имхо)
Если виртуальная машина превышает квоты на ресурсы, то ее...12.07.04 13:16 Автор: amirul <Serge> Статус: The Elderman
> > Вот только, если ты превысишь квоту - писать тебе > потом в > > саппорт хостера с вопросами о том, за что вырубили > сайт. > > Да не.. Наверное я не так выразился.. Я имел ввиду не > реализацию чатов и ротаторов, а именно реализацию баз. В > общем не понятен ответ. Если виртуальная машина превышает квоты на ресурсы, то ее просто вырубают. И никаких запретов на чаты. Делай сколько хочешь чатов, но следить за производительностью - твоя задача, а не хостера.
> (на практике я думаю сделать разбивку на каталоги - > максимум строчек десять кода - ничего сложного и хитрого в > алгоритме нет имхо) А в БД одна - вызов SQL-запроса. Для получения любых данных из базы - тоже одна. Я ж говорю, что БД имеют очень хорошие и простые интерфейсы. Не сложнее, чем интерфейсы работы с реестром или файлами.
На самом деле у БД свои приколы есть.12.07.04 13:46 Автор: Ktirf <Æ Rusakov> Статус: Elderman
> > (на практике я думаю сделать разбивку на каталоги - > > максимум строчек десять кода - ничего сложного и > хитрого в > > алгоритме нет имхо) > А в БД одна - вызов SQL-запроса. Для получения любых данных > из базы - тоже одна. Я ж говорю, что БД имеют очень хорошие > и простые интерфейсы. Не сложнее, чем интерфейсы работы с > реестром или файлами. Все так, вот только для мало-мальски надежной работы это добро надо констрейнтами окружать по полной программе. Причем в том, что ты правильно задал все констрейнты, ты тоже не можешь быть уверен. В отличие от файловой системы, в которой многие ограничения (хорошие) зашиты в архитектуру.
Хотя in the end БД по масштабируемости, естественно, лучше. Большинство реализаций БД на основе файловых систем (какие видел) характерно непоправимой наколеночностью.
В общем, главное правило, как и везде - знать инструмент. И как я где-то здесь уже недавно написал - если софт плохо спроектирован, его не спасут никакие средства реализации.
В NTFS нельзя выключить индексирование поиска файлов по имени... Можно отключить службу индексирования, которая индексирует контент, и FS ей по барабану. Ещё можно отключить обновление времени последнего доступа к файлам. Всё!08.07.04 13:28 Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 08.07.04 13:35 Количество правок: 1
> Проблема ФС в другом. Они не рассчитаны на работу с > десятками/сотнями тысяч файлов в каталоге. И даже по > ключевому полю - имени - поиск при таких масштабах будет > весьма небыстрым. Рассчитаны они замечательно на такие объемы :) Сабж.
А я не отключаю :-)07.07.04 17:34 Автор: amirul <Serge> Статус: The Elderman
> Рассчитаны они замечательно на такие объемы :) Сабж. Кстати, тебе не кажется странным совет отключать индексирование для ПОВЫШЕНИЯ быстродействия (во всех faq-ах и твикерах именно такое назначение отключения индексирования). Какое то индексирование странное там :-)
Если случайно залезть в этот каталог эксплорером можно очень долго ждать, потому как он обновляет время доступа к каждому файлу или что-то в этом роде.
В общем сильно сомневаюсь, что НТФС масштабируется настолько.
> > Рассчитаны они замечательно на такие объемы :) Сабж. > Кстати, тебе не кажется странным совет отключать > индексирование для ПОВЫШЕНИЯ быстродействия (во всех faq-ах > и твикерах именно такое назначение отключения > индексирования). Какое то индексирование странное там :-) Индексирование там вполне себе нормальное. По крайней мере поиск по 30 Гб файлов у меня работает удивительно быстро.
А отключать индексирование надо тогда, когда ты часто обновляешь данные на диске. Тогда, как и в любой БД, индексы приходится перестраивать... В частности поэтому у меня музыка и хомяки на доживающей свой век винде выброшены на отдельные разделы, на которых индексирование включено, а раздел, на котором стоит система, не индексируется.
> Если случайно залезть в этот каталог эксплорером можно > очень долго ждать, потому как он обновляет время доступа к > каждому файлу или что-то в этом роде. Есть такая фигня, но обновление времени доступа можно легко отключить, даром что им почти никто не пользуется.
> В общем сильно сомневаюсь, что НТФС масштабируется > настолько. Масштабируется, при наличии умелых рук, желательно прямо из MS. Должна же техподдержка свой хлеб отрабатывать.
Ну дык форум это ли не частое обновление?07.07.04 18:01 Автор: amirul <Serge> Статус: The Elderman
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
