Re: Повторяется вопрос про фидо и SQL

From

Vadim Goncharov (2:5020/400)

To

Dmitry Dootikov

Date

2005-06-10T11:54:48Z

Area

RU.UNIX.FTN

From: Vadim Goncharov <vadimnuclight@tpu.ru>

Hi Dmitry Dootikov! 

On Fri, 10 Jun 2005 00:51:32 +0400; Dmitry Dootikov wrote about 'Повторяется вопрос про фидо и SQL':

 VG>> Я просто до сих пор не вижу преимуществ использвоания SQL в таких
 VG>> случаях над ньюссервером :)
 DD> Тебе уже привели конкретный пример. Что тебе еще нужно? Могу привести тебе свой
 DD> пример. У меня на работе стоит о..енный сервак, на нем стоит 2003 винда, рядом
 DD> с ним стоит еще один о..енный сервак с супер о..енным дисковым массивом и
 DD> ораклем. Рядом стоит вспомогательная банка, с бздей которая рулит атской и
 DD> всяким сетевым оборудованием.

Я рад за тебя :)

 DD> Задача - построить ноду + сделать вебморду с возможностью писать.
 DD> Ограничение - никакого ломаного софта, либо фривар, либо покупать. Начальник
 DD> мне ньюссервер виндовый не купит, и фривар такого я не видел, ASPморд я не
 DD> видел к ньюс серверам.

Есть jamnntpd, InterSquish. Оба виндовые ньюс-сервера, работающие с
фидошными базами. Вебморда к ньюсам есть на PHP, но она не нужна вообще,
поскольку необходимый софт уже есть - Outlook Express на винде,
например.

 DD> Че делать? Лично мне проще из под бзди засунуть базы в ораклю, и написать
 DD> вэбморду к этой оракле которая будет крутиться на вебсерваке. А самому читать
 DD> это все голым дедушкой с прикрученым к нему sql.

Тебе времени своего на всё это не жалко?

 DD> Опять же решается вопрос многопользовательского доступа, мне не нужно просить у
 DD> начальства выделить мне место на диске, продумывать архивации бэкапы. Уже все
 DD> готово.

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

 DD> Это была реальная ситуация. Я тебе могу еще других, не существующих придумать.
 DD> это может быть поинту нифига не нужно, или тому кто фидошку из инета через
 DD> ньюсы тянет.

Задачи надо решать правильными инструментами, а не городить стройную
систему подпорок и костылей.

 DD>>>>> Впринципе я с ним согласен (в принципе), ибо любая SQL-таблица
 DD>>>>> многим лучше жамов, сквишей, хадсонов и опусов. Так что ничего
 DD>>>>> плохого не будет, если в голдед добавится еще один "формат
 DD>>>>> базы".
 VG>>>> Не один. Каждый SQL-тоссер будет хранить в своем формате, ага.
 DD>>> Это легко решается. Даже легче чем ты думаешь. Информацию о
 DD>>> формате можно хранить в самой базе, можно формат расписать в
 DD>>> конфиге, ничего особо хитрого тут нет. Да и пока тоссер один,
 DD>>> есть возможность и договориться :)
 VG>> Короче говоря, надо сначала договориться о стандарте.
 DD> Для этого есть официальные процедуры. Можно и между разработчиками
 DD> договориться. А можно и придумать процесс конфигурирования, ведь по сути
 DD> различия будут проявляться в именах полей. Каких-то кординальных различий быть
 DD> не может.

Не только в именах, но и в количестве и содержимом.

 VG>>>> Стандарта-то нет. Ньюс-сервер - самое праильное решение.
 DD>>> Ньюссервер - это "юниксвей". БД (сейчас преимущественно
 DD>>> самодельные) - это классический FTN.
 VG>> Классический FTN - он тоже unix way, ибо минимум 3 программы вместо
 VG>> универсального комбайна.
 DD> Вам в FAQ.

Аргументированные возражения есть?

-- 
WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
--- slrn/0.9.8.1 on FreeBSD 4.11/i386
 * Origin: Nuclear Lightning @ Tomsk, TPU AVTF Hostel (2:5020/400@fidonet)
SEEN-BY: 46/50 50/203 400/814 450/186 247 1024 451/30 454/9 461/43 640 465/285
SEEN-BY: 469/999 4616/3 4625/8 4627/10 4646/15 5000/76 5000 5001/5001 5002/50
SEEN-BY: 5002/79 5003/57 5006/1 5007/1 5010/53 70 5011/13 5012/23 5015/10
SEEN-BY: 5019/31 5020/52 118 154 175 194 400 545 715 758 765 830 937 1057 1523
SEEN-BY: 5020/1604 1922 2020 2142 2238 4441 5021/29 5022/128 5025/3 750
SEEN-BY: 5026/14 45 49 5027/16 5030/49 115 556 966 1063 1900 5031/70 5035/38
SEEN-BY: 5036/1 34 5042/13 5049/50 5051/15 5054/1 8 9 18 37 45 63 67 81
SEEN-BY: 5059/37 5061/15 120 5062/1 10 5063/3 5066/18 5067/2 5069/7 5070/1222
SEEN-BY: 5074/9 5075/35 5079/23 5080/80 1003 5081/2 5083/21 5085/13 5090/108
SEEN-BY: 5090/113 5092/1 5095/20 5096/18 5099/11 6000/12 254 6001/3 10 6009/1
SEEN-BY: 6090/1

PATH: 5020/400 4441 545 5054/1 37