Если вы ударите по лицу европейца, он заплачет. Если вы ударите по лицу американца, он подаст на вас в суд. Если вы ударите по лицу русского, знайте, ваши проблемы только начались
https://forum.lissyara.su/
http://www.lissyara.su/?id=1015kama_c_ytpa писал(а):Посоветуйте люди добрые:юзабельный, стабильный MTA с хранением полностью всего(логины/пассы/мыльники/сами сообщения) в базе MySQL
и ткните носом в нее. перерыл много чего, пока что в голове полный NULL =( уже сутки мучаюсь с DBmail + postfix =((
Ставь сразу Exim.Sun писал(а):Тоже ставлю MTA останавился на этом мануале http://www.sys-adm.org.ua/mail/mail-howto-p1.php
кривые рукипостоянные сбои
. Ему не хватает гибкости, но ни как не стабильности 
плохая идея, имхос хранением полностью всего(логины/пассы/мыльники/сами сообщения) в базе MySQL
незнаю насколько у меня кривые руки...вродь пока никто не жаловался))сервак с postfix'ом достался мне понаследству))) так сказать...что я с ним тока не делал...конешно сам postfix может быть и не виноват, так как почта все таки довольно нормально прыгала...НО вообщем как сказал Уважаемый Мной Лисяра...нет ни желания не времени заниматься почтарем который мне не нравится и неинтересен...Alex_hha писал(а):кривые рукипостоянные сбои
с хранением полностью всего(логины/пассы/мыльники/сами сообщения) в базе MySQL
ну почему же сразу плохая?))...плохая идея, имхо
это ближе к правденет ни желания не времени заниматься почтарем который мне не нравится и неинтересен...
Прочитайте назначение и смысл хранения данных в рел-ных БД.ну почему же сразу плохая?))...
Позволю себе не согласиться с данным утверждением и говоря этим же языком: Существуют формы нормализации, от которых приходится отказываться в пользу быстродействия и другим причинам. Следовательно утверждение, что использовать реляционную базу можно только по своему непосредственному назначению считаю недействительным. Отсюда - хранение учётных записей - дело вкуса и желания, хотя и не стоит конечно нагружать систему тем, что будет жрать ресурсы без надобности.Alex_hha писал(а):Прочитайте назначение и смысл хранения данных в рел-ных БД.
Не совсем понятно что Вы здесь хотели сказать...Alex_hha писал(а):это ближе к правденет ни желания не времени заниматься почтарем который мне не нравится и неинтересен...
Прочитайте назначение и смысл хранения данных в рел-ных БД.ну почему же сразу плохая?))...
разницу между МОЖНО и НУЖНО (целесообразно) улавливаем?Следовательно утверждение, что использовать реляционную базу можно только по своему непосредственному назначению считаю недействительным
это относилось к хранению писем в БДОтсюда - хранение учётных записей - дело вкуса и желания, хотя и не стоит конечно нагружать систему тем, что будет жрать ресурсы без надобности.
Очень хорошо. А теперь объясните мне, хотя бы 2-3 причины, по которым стоит хранить письма в рел-ной БД? Может я чего то не знаю или не понимаю.Уверяю Вас что я не только читал теорию реляционных БД, но и постоянно сталкиваюсь со всем этим на практике.
выбор должен быть обоснованным, а не - "А я вот слышал, что крутые пацаны ВСЕ хранят в БД"Вообщем то можно очень долго и упорно обсуждать тему плюсов и минусов хранения оговорённых выше данных (логины/пассы/мыльники/сами сообщения) в БД, но думаю это не та тема)), думаю kama_c_ytpa сам сделает выбор.
. Если предполагается как условие функционирования почтовой системы хранение сообщений в БД, значит и ресурсы под это выделяются соответственные..объясните мне, хотя бы 2-3 причины, по которым стоит хранить письма в рел-ной БД
для меня причины по которым я дополнительно храню сообщения в БД это удобство, быстрота оперирования со всем этим барахлом, при этом все работает быстро при таком объеме Не все крутые пацаны ВСЕ хранят в БД совсем не всевыбор должен быть обоснованным, а не - "А я вот слышал, что крутые пацаны ВСЕ хранят в БД"
и почему выбрал такую связку Dbmail+Postfix? просто интересно?потому что для это нет никаких предпосылокВсе это очень хорошо вписывается в рамки теории реляционной модели И почему бы их не хранить БД?.
очень хорошо, вы делаете сложные выборки с джойнами, сортировкой и т.п. по письмам? Если нет, то и нет смысла использовать реал-ную БДВ рел. базах согласно принципам положеным доктором Коддом, в общем смысле все данные представлены в виде простых таблиц, разбитых на строки и столбцы, на пересечении которых расположены данные, запросы к таким таблицам возвращают таблицы, которые сами могут становиться предметом дальнейших запросов.
что вы имеете ввиду под словами - "удобно оперировать" в контексте писем? С учетками согласен.Я использую дополнительно БД для хранения и учеток и разобранных сообщений только для того чтобы ими было удобно оперировать. Работать с сообщениями полтысячи учеток, когда почтовый трафик достаточно сильный, очень трудно.
Мм..ну сложных объединений насколько я помню у меня не было))да и сложно придумать задачу относительно кучи сообщений где они бы пригодились...но достаточно сложные запросы по разборкам сообщений как конкретных пользователей так и общей массы разобранных сообщений я делал и делаю (вот таким иногда приходится заниматьсявы делаете сложные выборки с джойнами, сортировкой и т.п. по письмам?
), и хранение в БД совместно с sql здесь очень оказалось уместным)), а как бы я сделал если использовать только стандартный способ даже и незнаю . "удобно оперировать" это и значит совершать необходимые операции (их достаточно много как оказывается можно придумать относительно сообщений и всяких учеток и паролейчто вы имеете ввиду под словами - "удобно оперировать" в контексте писем? С учетками согласен.
) за минимум времени с максимальным эффектом .Ну а с учетками какие операции, да толком и никаких, добавление, изменение, удаление, выборка вродь и все..как особо популярные)) , отнюдь просто не стоит отказываться в некоторых случаях и от такого способа хранения, и он весьма хорош. Вы со мной не согласны?