|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Maxim Timofeyev 2:5030/1763.1 24 Mar 2004 12:46:31
To : Svyatoslav Abramenkov
Subject : Re: небольшой POP3-сервер помощнее popa3d
--------------------------------------------------------------------------------
MT>> Hе думаю, что было бы бы тоже самое. Этот now() вставился бы именно с
MT>> тем значением, когда конкретно произошла вставка. Hе могу похвастаться,
MT>> что у меня была дикая загрузка и из-за этого я не мог проверить подобных
MT>> вещей.
SA> Так то-то и оно, что важен момент снятия данных, а не когда оно
SA> конкретно вставилось. Там перед этим шло определение ID правила по строке из
SA> /proc/net/ip_fwchains, а уж потом вставка с нужным ID и timestamp.
Я писал применительно к случаю, когда дата вносится в базу при INSERT и
отображает время добавления записи.
При UPDATE такого не произойдет, там default уже не прокатывает.
Как я понимаю, если в твоем случае делать в твоей программе time() и
узнавать ID (теоретически это происходит одновременно), то нет никакой
разници через сколько конкретно времени будет данная запись вставлена
(INSERT) в твою БД, т.к. твой time() соответствует времени получения ID.
Короче говоря я не совсем понял что именно ты вставляешь и что чему
должно соответствовать. ;)
MT>> Я вижу сам, и меня все время убеждают, что лучше писать программу
MT>> использующую C'шну библиотеку (даже под Win32 я просто собрал
MT>> libpq.dll), нежели всякие ODBC. perl тут вообще никаким боком.
SA> Hу, под win32 я пользую ZeosDBO для Delphi, а оно работает через
SA> биндинги клиента (libmysqlclient, libpq.dll и т.д.), как и
SA> перловые DBD::xxx, кстати.
Я использую напрямую, как уже писал, и не жалуюсь. Считаю это более
правилным подходом. Кстати и переносимым тоже. Правильным по причине
скорости работы такого приложения (без посредников) и возможности
использовать специфику СУБД, которая может уменьшить время выполнения и
т.п.
MT>> Конечно я имею ввиду свою задачу. Hу даже возьмем случай, из которого
MT>> вырос весь это флейм -- берем БД для авторизации pop3 пользователей.
MT>> Ты pop3 сервер будешь писать на perl'е? Hе спорю -- есть такие. Или ты
MT>> предлагаешь делать некий враппер? А смысл?!! Тут на C писать -- самое
MT>> то. Да и родная библиотека всегда быстрее будет. Хотя бы из-за
MT>> возможности использовать специфику конкретной БД.
SA> Я, наверное, всё же буду пользоваться более стандартными вещами, и
SA> авторизовать пользователей из LDAP. А уж LDAP будет хранить свою базу там,
SA> где умеет, и скорее всего это будет в моём случае не mysql - объёмы не те,
SA> а следить еще и за mysql в таком случае неохота, проще всё в фаёлах хранить.
SA> И возьму готовый pop3 или imap сервер, который это уже умеет. Hо, говоря по
SA> правде, pop3 вполне можно и на perl написать, тем более, что на CPAN есть
SA> такая штука, как Net::Server::POP3.
Можно, я не говорил, что нельзя. Я об объеме занимаемой памяти
беспокоюсь... Сам perl отожрет немерянно, тем более запущенный в
нескольких вариантах.
По поводу готового не все так просто. Если берешь что-то готовое, то оно
не обязательно будет достаточно защищенным. В случае же с popa3d хоть с
этой точки зрения можно быть спокойным.
SA>>> Hу вот. 2 года назад было то же самое.
MT>> Hу так ставь родной под любой Unix и не парься. Зачем какими-то Win32
MT>> эху засорять? ;-)
SA> У меня есть клиенты, у которых это надо на отладку ставить. Им проще не
SA> покупать дополнительную машину раньше времени и не пускать ради такого дела
SA> vmware (которое, кстати, не работает на вымирающих win9x/ME).
Я применительно к тому, что эха зовется RU.LINUX, а не RU.WINDOWS... ;)
SA>>> Hе очень. Я осенью этот вопрос исследовал.
MT>> Hу я не рассматриваю всякие мелкие хостишки, на которых хоститься-то
MT>> себе дороже... Хотя я даже не пытался исследовать этот вопрос, но нашел
MT>> хостинг с PostgreSQL мгновенно. Видно плохо искал. ;)
SA> Проект еще раскрутить надо, и дешевле это делать за $7/мес, чем за
SA> $30/мес. За $60/мес. уже дешевле будет к себе канал протянуть, но до этого
SA> еще надо дожить.
Я могу конечно опять глянуть кто именно дает PostgreSQL на хостинге, но
цен в $30/мес я давно не видел. Именно по этой причине я и отказался сам
хостингом заниматься. ;) Дешево, а проблем немерянно.
SA>>> PostgreSQL я в том или ином виде щупал, начиная с 1999 года. Hо
SA>>> Sybase 5.5 был на тот момент лучше, а лицензирование вообще вспоминалось
SA>>> только касательно поддержки.
MT>> Как бы Sybase ты без денег вообще не скачаешь. ;) Вроде только какую-то
MT>> триальную версию с ограничениями какими-то. Я не изучал этот вопрос.
SA> Как обычно, сходить к друзьям и винтом забрать. Hо в том случае я его
SA> вообще купленный получил, была закупка под проект, и разработчики себе
SA> скопировали дистрибутив, кому надо.
Я не рассматривал вопрос по обычному отечественному походу к задаче
обзаведения новым ПО. Т.е. я рассматривал вопрос о легальном
использовании всего используемого ПО. PostgreSQL можно вполне легально
скачать из интернета и использовать, что про Sybase не скажешь.
Хотя если финансирование позволяет, то можно и $50000 отдать...
Именно столько наша контора заплатила за Sybase... Или что-то около
того...
MT>> Хотя я обхожусь и версией с www.postgresql.org не плятя никому ни
MT>> копейки. Мне хватает. Пока не было у меня задачь, где бы он не
MT>> справился. ;)
SA> Мне тоже пока не попадалось.
Тем более. А к чему тогда претензии по поводу VACUUM? ;)
--
GPG key ID: 55F6ADEC fp: 0BDE AC68 5418 B40A 0C85 C081 037A 6542 55F6 ADEC
[2:5030/1763@fidonet.org][tmahome@tma.spb.ru][http://tma.spb.ru]
--- tin/1.5.16-20030125 ("Bubbles") (UNIX) (Linux/2.4.20-alt10-up (i686))
* Origin: TMA at HOME (2:5030/1763.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
