нужен совет

[kama_c_ytpa]

Посоветуйте люди добрые:юзабельный, стабильный MTA с хранением полностью всего(логины/пассы/мыльники/сами сообщения) в базе MySQL
и ткните носом в нее. перерыл много чего, пока что в голове полный NULL =( уже сутки мучаюсь с DBmail + postfix =((

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[LMik]

Посоветуйте люди добрые:юзабельный, стабильный MTA с хранением полностью всего(логины/пассы/мыльники/сами сообщения) в базе MySQL
и ткните носом в нее. перерыл много чего, пока что в голове полный NULL =( уже сутки мучаюсь с DBmail + postfix =((

http://www.lissyara.su/?id=1015

[Sun]

Тоже ставлю MTA останавился на этом мануале http://www.sys-adm.org.ua/mail/mail-howto-p1.php

[dikens3]

Тоже ставлю MTA останавился на этом мануале http://www.sys-adm.org.ua/mail/mail-howto-p1.php

Ставь сразу Exim.

[estade]

Поддерживаю dikens3. Стоит в связке exim + mysql + vexim + exilog, и логины и пасы и все остальное хранится mysql, а exilog разбирает сообщения и сует их в базу, для обоих есть достаточно юзабельные веб интерфейсы..у меня Exim пашет стабильно без сбоев (всего около 800 учеток), Postfix как то не прижился, постоянные сбои (может быть просто не умею настраивать postfix, да и желания с ним возиться не было) настраивается все это дело достаточно легко..Меня пока все устраивает..

[Alex_hha]

постоянные сбои

кривые руки . Ему не хватает гибкости, но ни как не стабильности

с хранением полностью всего(логины/пассы/мыльники/сами сообщения) в базе MySQL

плохая идея, имхо

[estade]

постоянные сбои

кривые руки . Ему не хватает гибкости, но ни как не стабильности

незнаю насколько у меня кривые руки...вродь пока никто не жаловался))сервак с postfix'ом достался мне понаследству))) так сказать...что я с ним тока не делал...конешно сам postfix может быть и не виноват, так как почта все таки довольно нормально прыгала...НО вообщем как сказал Уважаемый Мной Лисяра...нет ни желания не времени заниматься почтарем который мне не нравится и неинтересен...

с хранением полностью всего(логины/пассы/мыльники/сами сообщения) в базе MySQL

плохая идея, имхо

ну почему же сразу плохая?))...

[Alex_hha]

нет ни желания не времени заниматься почтарем который мне не нравится и неинтересен...

это ближе к правде

ну почему же сразу плохая?))...

Прочитайте назначение и смысл хранения данных в рел-ных БД.

[dikens3]

Прочитайте назначение и смысл хранения данных в рел-ных БД.

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

[estade]

нет ни желания не времени заниматься почтарем который мне не нравится и неинтересен...

это ближе к правде

ну почему же сразу плохая?))...

Прочитайте назначение и смысл хранения данных в рел-ных БД.

Не совсем понятно что Вы здесь хотели сказать...

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

Вообщем то можно очень долго и упорно обсуждать тему плюсов и минусов хранения оговорённых выше данных (логины/пассы/мыльники/сами сообщения) в БД, но думаю это не та тема)), думаю kama_c_ytpa сам сделает выбор.
ЗЫ. Простите за мой сумбурный ответ, как никак ночь на дворе

[Alex_hha]

Следовательно утверждение, что использовать реляционную базу можно только по своему непосредственному назначению считаю недействительным

разницу между МОЖНО и НУЖНО (целесообразно) улавливаем?

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

это относилось к хранению писем в БД

Уверяю Вас что я не только читал теорию реляционных БД, но и постоянно сталкиваюсь со всем этим на практике.

Очень хорошо. А теперь объясните мне, хотя бы 2-3 причины, по которым стоит хранить письма в рел-ной БД? Может я чего то не знаю или не понимаю.

Вообщем то можно очень долго и упорно обсуждать тему плюсов и минусов хранения оговорённых выше данных (логины/пассы/мыльники/сами сообщения) в БД, но думаю это не та тема)), думаю kama_c_ytpa сам сделает выбор.

выбор должен быть обоснованным, а не - "А я вот слышал, что крутые пацаны ВСЕ хранят в БД"

[estade]

Ну допустим у меня основное место хранения писем не СУБД как таковое
Опять же про "жрать ресурсы без надобности", думаю все таки хотя бы при первичном проектировании системы почтовой или другой таковой всегда закладываются необходимые ресурсы при которых эта система будет функционировать. Думаю никто не будет старый пенёк использовать для хранения сообщений почтовой системы в БД допустим хотя бы со средним объемом трафика, ибо это полная Ж... . Если предполагается как условие функционирования почтовой системы хранение сообщений в БД, значит и ресурсы под это выделяются соответственные.
Я использую дополнительно БД для хранения и учеток и разобранных сообщений только для того чтобы ими было удобно оперировать. Работать с сообщениями полтысячи учеток, когда почтовый трафик достаточно сильный, очень трудно.

объясните мне, хотя бы 2-3 причины, по которым стоит хранить письма в рел-ной БД

.
А что такое вообще реляционная БД и для чего она предназначена..В рел. базах согласно принципам положеным доктором Коддом, в общем смысле все данные представлены в виде простых таблиц, разбитых на строки и столбцы, на пересечении которых расположены данные, запросы к таким таблицам возвращают таблицы, которые сами могут становиться предметом дальнейших запросов. Что представляют собой почтовое сообщение как единица, такой же кортеж, та же сущность, вернее ее экземпляр. Все это очень хорошо вписывается в рамки теории реляционной модели И почему бы их не хранить БД?.
Назовите 2-3 причины по которым не стоит хранить сообщения в рел. БД. для меня причины по которым я дополнительно храню сообщения в БД это удобство, быстрота оперирования со всем этим барахлом, при этом все работает быстро при таком объеме
Да есть свои недостатки и в этом...например как еще одно звено отказа это сам сервер БД, проблема нормализации и тд и тп.

выбор должен быть обоснованным, а не - "А я вот слышал, что крутые пацаны ВСЕ хранят в БД"

Не все крутые пацаны ВСЕ хранят в БД совсем не все

Хотел бы все таки услышать что же выбрал kama_c_ytpa и почему выбрал такую связку Dbmail+Postfix? просто интересно?

[Alex_hha]

Все это очень хорошо вписывается в рамки теории реляционной модели И почему бы их не хранить БД?.

потому что для это нет никаких предпосылок

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

очень хорошо, вы делаете сложные выборки с джойнами, сортировкой и т.п. по письмам? Если нет, то и нет смысла использовать реал-ную БД

Я использую дополнительно БД для хранения и учеток и разобранных сообщений только для того чтобы ими было удобно оперировать. Работать с сообщениями полтысячи учеток, когда почтовый трафик достаточно сильный, очень трудно.

что вы имеете ввиду под словами - "удобно оперировать" в контексте писем? С учетками согласен.

[estade]

вы делаете сложные выборки с джойнами, сортировкой и т.п. по письмам?

Мм..ну сложных объединений насколько я помню у меня не было))да и сложно придумать задачу относительно кучи сообщений где они бы пригодились...но достаточно сложные запросы по разборкам сообщений как конкретных пользователей так и общей массы разобранных сообщений я делал и делаю (вот таким иногда приходится заниматься ), и хранение в БД совместно с sql здесь очень оказалось уместным)), а как бы я сделал если использовать только стандартный способ даже и незнаю .

что вы имеете ввиду под словами - "удобно оперировать" в контексте писем? С учетками согласен.

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

Вообщем то я в конечном смысле и не утверждаю что ВСЕ поголовно должны хранить почтовые данные, упомянутые выше только в БД ибо это КРУТОТЕНЬ и так должны поступать крутые пацаны , отнюдь просто не стоит отказываться в некоторых случаях и от такого способа хранения, и он весьма хорош. Вы со мной не согласны?