Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1] 2  Все   Вниз
  Печать  
Автор Тема: Минимальная структура базы данных форума  (Прочитано 68797 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« : 22-04-2004 13:00 » 

Привожу пример минимальной структуры базы данных!

Таблицы

1. SECTIONS - Разделы форума (у нас Служебное, Программирование и т.д.)

Поля

ID - уникальный Идентификатор раздела с автоинкрементом
Name - Имя раздела
count_of_forums - колличество форумов в разделе
section_order - порядок вывода секций
Type - закрыт/открыт - прива/ неприват и т.д. - для всех секций оределяется маска типов и записывается!!!

2. FORUMS - Список форумов (Все форумы)

Поля

ID - /-/
Section ID - id - секции к которой принадлежит форум
Name
TYPE - установки для форумов (в той же форме что и для разделов но другие по смыслу)
count_of_thems - только внутри форума
count_of_msg - только внутри форума
forum_order - порядок вывода форумов в секциях

3. THEMS - Список всех тем (Все форумы)

Поля

ID
forum_id - ID форума к которому принадлежит
name
TYPE - набор настроек для текущей темы!
count_of_msg - колличество ответов
start_msg_usr_id - ID - пользователя создавшего тему
last_msg_user_id - ID - последнего отвечавшего
start_msg_TXT - Стартовый текст которым открыта тема!

4. USERS - Список пользователей

Поля


ID
Name
email
passwd
count_of_msg - колличество посланных сообщений
count_of_thems - колличество начатых им тем
reputation - репутация (надо решить как ее улучшить и связать со званиями)
Status - звание  
Special status - спец звание (типа Модратор или заслуженный флудер)

-------------------
Примечание: Здесь должны быть все настройки пользователя как подпись аватар и т.д. но так как пока все не работает а они пока не так важны я не пишу подробности!
-------------------

5. ACCESS_LEVELS

Эту структуру надо продумать нга какие уровни допуска разделить и как структурировать уровни клубных приоритетов

В данный момент они таки:

- Гость
- Регитрированный
- Модератор
- Админимтратор

6. Forum_config's

Тоже обычные настройки форума - фремя и т.д. к которым надо будет подходить постепенно - запись в таблице будет только одна - поэтому колличество полей будет зависеть от возможностей конфигурации и будет постоянно добавляться!

7. POST - Таблица всех сообщений (кроме стартовых в темах)

ID
msg_txt - текст сообщения
msg_name - заголовок - если отличается от основного заголовка темы!
theme_id - id - темы к которой принадлежит сообщение
msg_time - время ввода
sender_id - кто послал!

------------------
Примечание: тоже пока не пишу конфигурационные параметры - которые будут формироваться потом в зависимости от функциональности
------------------


8. SECURITY
Это пока не совсем понятная мне самому таблица - но тут будут данные о забаненых людях и вообще всякие настройки против флуда и т.д.



Примечание ко всему

Думаю понятно, что в каждойтеме и у каждого пользователя есть время последнего сообщения и время регистрации - время последнего прибывания на форуме и Т.Д. я их пока не пишу - как не пишу и некоторые вещи типа групп пользователей групп по интересам по модераторским уровням групп по упроавлению САЙТОМ - не привязываю пользорвателя к сайту вообще - т.е. единственная общая таблица - пользователи пока - там даьше надо это все оценить!!!

Жду ваших оценок и критики!

Да и желательно по активнее !!! Ведь время идет !!!!
Записан

А птичку нашу прошу не обижать!!!
Kuzmich
Гость
« Ответ #1 : 23-04-2004 03:56 » 

Для моего малоопытного взгляда, все логично, так и должно быть. :l_up:
Вопрос: какой тип у поля TYPE ?
(это я так, чтобы активность поддержать Улыбаюсь )
Записан
Fireworm
Гость
« Ответ #2 : 23-04-2004 06:35 » 

Мне кажется не стоит разделять Sections, Forums и Thems - т.к. это объекты одного типа, и их можно сделать в виде древовидной табличке. К тому же увеличится расширяемость, т.к. можно будет делать дерево форумов.
Так же не стоит делать поля count - во первых будут большие трудности при подсчетах во время insert или update, например при одновременном постинге 2-х сообщений, а блокировок в mysql практически нет.

Сейчас накидаю схемку БД как бы я это сделал...
Записан
Fireworm
Гость
« Ответ #3 : 23-04-2004 07:03 » 

А ка бы сюда добавить каритинку со структурой БД?
Записан
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #4 : 23-04-2004 07:05 » 

Fireworm, ну во первых в MySQL есть блокировка как мне известно!
Во вторых - коунт можно не вводить, а вычислять при запросах. Это вполне можно сделать! Только при большой вложенности форумов посчитать колличество сообщений принадлежащих кому - то в каких то форумах определенных - получается не один, а несколько запросов Жаль

Sections, Forums и Thems - объекты совершенно разных типов!

Sections - это только набор форумов - в нем не может быть ни тем ни сообщений без созданного форума

Forums - имеет только темы (но не имеет сообщений и форумов)

Тема - это именно контейнер для сообщений - который содержит текст первого сообщения для темы!!!

Каждый из этих объектов имеет разный тип TYPE ! Причем очень разный как по типу доступа, так и по типу вообще!!!

Хотя все надо обдумать!


Kuzmich, строка 255 символов в длину! Можно конечно иметь и бинарную форму - но так проще - каждый символ кодирует одно из свойств!

Может иметь несколько значений (0-1-2-3-4-5-6) которые можно заранее предопределеит для каждого типа таблицы!!!
Записан

А птичку нашу прошу не обижать!!!
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #5 : 23-04-2004 08:06 » 

В таблице Tables добавлен forum_order - порядок вывода форумов в секции
В таблице Sections добавлен section_order - порядок вывода секций
Убраны cjuntofthems & countofmsg за ненадобностью
Записан

А птичку нашу прошу не обижать!!!
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #6 : 23-04-2004 19:41 » 

Fireworm, вышли мне на почту, вот собственно и все!
Записан

А птичку нашу прошу не обижать!!!
Fireworm
Гость
« Ответ #7 : 26-04-2004 06:26 » 

Отправил. Смотри почту
Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #8 : 26-04-2004 10:06 » 

Гром, как я понимаю, за основу ты взял базу phpBB?

Такие комментарии:
3. и 7. - id пользователей. Как писать без регистрации? В phpBB есть альтернатива - поле для имени в посте. Правда, нужно ли это - можно, для простоты, всех нерегистрированных считать одним и тем же анонимом.

7. - не помешает время изменения. Да и ip полезно записывать - в вопросах модерации вещь полезная.

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

Контроль доступа тут самая сложная вещь. Предлагаю все сделать по группам. Т.е. к форуму приписывается три группы (чтение, запись, модераторы), в котрые добавлять пользователей. Завести пару специальных пользователей: "аноним" и "все зарегистрированные". Если, к примеру, форум доступен всем для чтения, но для записи только зарегистрированным, то в группу чтения добавить "аноним" и "все регистр.", а в группу "все регистр.". Нечто вроде ACL.
Стоит обдумать.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Fireworm
Гость
« Ответ #9 : 26-04-2004 12:00 » 

RXL, Для форума нет необходимости строить все дерево. Надо только выводить ветки выбранной ноды. Да кроме того, если брать 4 мускуль, то там помоему уже есть конструкции для построения древовидных запросов.
Контроль доступа - определяется простыми джойнами (В том варианте структуры, что я предложил, если Гром выложит).

А phpBB - за основу лучше и не брать, т.к.  эта программа - пример и плохого проектирования БД и плохого кодирования.
Записан
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #10 : 26-04-2004 12:24 » 

RXL, нет я не брал за основу  phpBB  а гостей ИД = 0

Fireworm, Я конечно выложу - причем сегодня - же!!!
Записан

А птичку нашу прошу не обижать!!!
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #11 : 26-04-2004 16:03 » 

Вот видение базы Fireworm!

Пояснение обязательно!!!
Записан

А птичку нашу прошу не обижать!!!
x77
Команда клуба

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #12 : 26-04-2004 17:41 » 

Fireworm, что-то нравится, что-то - нет.

1. древовидная структура топиков - замечательно. но чтобы её использовать, нужна рекурсия. в май-скл в запросе использовать рекурсию нельзя, остаётся что? в пхп? которое и так тормознутое? чтобы вывести древовидную структуру раздела / форума / темы с неизвестным порядком вложенности, тебе придётся для каждой записи выполнить запрос и для результирующего запроса опять выполнять запрос для каждой, и так без конца, пока запрос не окажется пустым. у тебя сервак, при 2-3 тысячах тем, просто ляжет на одном единственном пользователе. потому что при отображении страницы  будет выполняться не один запрос, как сейчас, а десятки - сотни таких запросов.

дерево приемлемо только при одном условии - что как таковое, оно не отображается. т.е. вывели главную страницу, юзер щёлкнул на разделе, вывели список подразделов (с фильтрацией по where), и т.д. спрашивается, насколько нужно дерево, которое в явном виде никогда не отображается? я не вижу смысла.

2. по доступу. он должен организовываться не на уровне юзверя, а на уровне роли. в терминологии форума - группы, к которой юзверь принадлежит.  иначе твоя линковочная таблица topic_accessх будет весить столько же, сколько весь форум. подчситай, для 10 тысяч топиков и 1 тысячи пользователей при 5, к примеру, видах доступа, сколько в ней будет записей? 50 тысяч? и при отображении каждого топика для каждого юзверя надо будет проверить, а есть ли у него право на просмотр этого топика? это неправильно в корне.

в общем, я согласен с Rxl.

RXL, не надо трёх групп. лучше примерно так:

Гость - имеет право читать всё, кроме закрытых форумов.
Зарегестрированный - читает и пишет везде, кроме закрытых; удаляет и правит только свои
Модер - читает всё; пишет везде, кроме закрытых; удаляет и правит везде, где он модер
Админ: читает, пишет, правит и удаляет всё и везде.
Записан

Fireworm
Гость
« Ответ #13 : 27-04-2004 06:20 » 

x77,
1. Даже если и не приходится строить дерево - выйгрыш в древовидной структуре - это что мы можем делать любой уровень сложности. Причем все хранится в одной таблице, что значительно облегчает хранение, а в особенности поиск.
Да и кто вам сказал, что php такой уж тормозной? С откомпилированным С кодом его сравнить, конечно же, трудно. Но по сравнению с perl и ASP - он очень-таки быстр.

2. А разве 50 тыс. - это большой объем для БД? Это можно сказать слезы. Даже 500 тыс. - это не те объемы над которыми надо задумываться.
К тому же если еще и корректно индексы расставить, то все будет очень быстро. Да ктому же все получается одним запросом:
Код:
SELECT topic_name
FROM topics t
   ,  topic_access ta
   , users u
WHERE t.topic_id = ta.topic_id
AND ta.user_id = u.user_id
AND u.user_id = 12
AND t.topic_parent_id = 7
AND ta.access_type_id > 3

К примеру вот этот один запрос выведет  все форумы с определенными правами.

Преимущества, что бы использовать персонализированный доступ против ролевого:
1.  Гибкость управления. Можно забаринт пользователя на постинг только в определенных разделах. Можно даже запретить кому-то писать в определенную тему (на случай, к примеру, если в какой-то теме 2 пользователя затеяли спор, который перерос на личности - банним обоих на эту тему и никто не обижается).
2. В эту же табличку ложится права хозяин темы.  На предмет закрытия темы.

Хотя в ролевом методе тоже много преимуществ - и основное - упрощенность в администрировании.
Можно и табличку users  слегка модифицировать. Что бы названия ролей - были пользователями . а уровень вхождения пользователей и групп задавать такой табличкой:
-----------------------
| parent_user_id   |
| child_user_id      |
-----------------------
| flag                   |
----------------------
Таким образом можно сделать, что пользователь может быть членом нескольких ролей сразу.

Но опять таки - это мое мнение. Мне кажется так будет более гибко. А на счет объемов БД - об этом стоит думать, когда количество записей измеряется миллионами, да и то в сторону перехода на более человеческую БД.
Записан
x77
Команда клуба

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #14 : 27-04-2004 06:46 » 

Fireworm, 50 тысяч - условная цифра. сколько на форуме пользователей? сколько на форуме тем? сколько видов прав? перемножь эти цифры. и получишь таблицу, в которой надо рыться при каждом действии юзверя. я согласен, для нормальной базы - это не объёмы. но зачем они нужны, если можно обойтись одной таблицей с десятком записей, по которой функцией будет строиться карта доступа по id-нику юзверя.

насчёт таблицы с пользователями. иерархию, т.е. так называемое дерево прав, строить не стоит. потому что у тебя будет куча проблем с перекрыванием этих прав. лучше сделать ещё одну таблицу, именно для принудительного разрешения/запрещения действий определённого юзверя в определённой теме.
типа того:
user_id
topic_id
operation (read,write,edit,delete,close,etc)
access (два значения: granted и denied)

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

так гораздо быстрее, чем шариться по рекурсиям.

т.е. смысл в том, что права пользователя надо разграничить: стандртные права, даваемые по умолчанию, и доп. права, даваемые или отбираемые для конкретных людей на конкретные действия в конкретных форумах/темах.
Записан

Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #15 : 27-04-2004 08:20 » 

Я сразу отсеку древовидность вывода тем, нет и не удобно, форумы давно спрогрессировали в нормальный табличный вид, моя жена как древовидный увидит - матюкается, говорит, что теперь на каждую ссылку кликать?

Запросы в табличных форумах, тоже проще и быстрее.

Предложение такое, делаем табличную форму, большую часть фич оставляем пока на будущее - никаких пока пермишнсов.

Надо просто сделать движок на котором посмотреть и адаптировать скорость запроса и корость работы форума, и потом вставлять время даты, как рекомендует RXL естесвтенно поля прописаны не все....

А добавить еще форумы в форумах, в виде дерева можно очень легко!
Делается два указателя ID_NEXT ID_PREV и все - разрешить при добавлении форума указывать его предыдущие форумы а не только секции.
Записан

А птичку нашу прошу не обижать!!!
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #16 : 27-04-2004 10:17 » 

Извиняюсь, немного не в тему, но хотелось бы сказать:
Цитата: Fireworm
Да кроме того, если брать 4 мускуль, то там помоему уже есть конструкции для построения древовидных запросов.
Если речь о вложенных запросах, которых до 4.0 небыло, то для этого надо знать число ступеней дерева.

Используя древовидную структуру форума, нужно ли контролировать права на каждый нод - может достаточно вершего уровня?

Гром, структуру лучше продумать заранее, чем потот ставить "неродные" заплатки, которые создадут дополнительные тормоза.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #17 : 27-04-2004 10:35 » 

Fireworm, 50т строк - это конечно пустяки, но как я уже упомянал, надо понимать ситуацию. Мы на сервере не одни - за дешевый тариф на один физический сервер с 1-2 процами и 1Г памяти вешают по 20 виртуальных серверов. Оттуда и тормоза - apache и mysql там стоят в одном экземпляре.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #18 : 27-04-2004 10:49 » 

RXL, по виртуальному хостингу абсолютно верно, когда я один стою, сайт с моего родного компа на канале в 12 КБ в сек грузится визуально в трое быстрее чем с сервака намастерхосте именно потому, что у менч я сам один.

Ладно все фигня пока, все равно купим потом сервер...

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

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

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

А птичку нашу прошу не обижать!!!
Fireworm
Гость
« Ответ #19 : 27-04-2004 11:18 » 

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

И я говорил не о вложенных запросах, а о запросах построения древовидных данных. Что-то типа CONNECT BY PRIOR в Oracle. Я не помню как эта конструкция в MySql обзывается.

Гром, Я потому и предлагаю хранить все в древовидной структуре (совсем не обязательно это и выводить пользователю в виде дерева).  Это совсем не расходится с возможностью отображения форума в виде таблицы. Зато заранее закладывается определенная гибкость, которая потом может очень сильно пригодится. А по поводу аттрибутов - можно сделать табличку аттрибутов и табличку соответствий, как в моем варианте users, user_params и params. Что бы для добавления нового аттрибота было достаточно добавить 1-2 записи в необходимые таблицы, а не изменять структуру таблиц.
Записан
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #20 : 27-04-2004 12:03 » 

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

И к тому же мне непонятно дерево! Зачем.

Вот максимальное дерево которое я вижу в форуме...

Секция 1 +
               Форум 1 +
                             Форум 1-1 (это возможно надо возможно нет)
                             Форум 1-2 +
                                             Тема +
                                                      Сообщение

В такой структуре ВСЕ форумы организуются с помощью перекрестных ID
ID_PREV + ID_NEXT в структуре даты, глубина влоежнности не имеет значения.

При том, что больше 20-30 форумов на страницу делать вообще не реально - бессмысленно, то получается что выборка в таблице из 30 пунктов несущественна.

Секций и того меньше...
Вывод - напрашивается
1. Таблица Секций с внедренными свойствамиэ
2. Таблица Форумов с внедренными свойствами и в структуре есть

ID - личный
ID_SECT - к какой секции
ID_PREV - если 0 то форум не принадлежит другому форуму если цифра то принадлежит форуму с таким ID

При необходимости выборки какие форумы принадлежат кому делается запрос
SELECT * from FORUMS WHERE ID_PREV=ID AND (OR) ID_SECT = ID_SECT_MY

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

Ну и сообщения, как и говорил - самое словжное - где применить тут дерево???

Другое дело связки между темами и свойствами как форумов так и секций обязательно надо сделать....
Записан

А птичку нашу прошу не обижать!!!
Never
Команда клуба

ua
Offline Offline
Пол: Женский

« Ответ #21 : 01-05-2004 14:22 » 

опа! Как-то я эту темку пропустила! Ух счас как начитаюсь...
Записан

не умеете летать- не мучайте метлу!
Kuzmich
Гость
« Ответ #22 : 05-05-2004 08:08 » 

какая версия апача и ьускула используется, а то у меня чето куча варнингов, хотя движок работает
Записан
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #23 : 05-05-2004 11:21 » 

Kuzmich, просто отключи wаrnings  в настройках php.

Я точно не знаю какая используется смотри описание на masterhost.ru

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

Смотрите полностью как устроен объект site в файле class.php

На этой структуре удобно строить модульность не меняя старый объект а наследуясь и меняя только тип вызова для новых модулей, скажем для написания нового модуля к сайту пишется объект наследник и файл работающий через него, не меняя исходный текст самого скрипта!!!
Записан

А птичку нашу прошу не обижать!!!
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #24 : 05-05-2004 12:18 » 

Сложно у них что-либо найти, но можно:
http://support.masterhost.ru/phpinfo.html
http://masterhost.ru/support/doc/php/#modules
http://masterhost.ru/support/doc/
MySQL 3.23.58
PHP 4.3
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #25 : 05-05-2004 13:16 » 

RXL, спасибо.

ИМХО в данном случае на появление ворнингов не влияет версия....
Я писал систему с таким расчетом, что бы колличество ворнингов уменьшить или вообще свести к минимуму. Все скрипты которые я качал домой вызывали у меня предупреждения дома, кроме моего, это никогда не происходило при установке их на нормальный реальный сервер....

Кузьмич, может приведешь пару примеров твоих предупреждений....
Записан

А птичку нашу прошу не обижать!!!
Kuzmich
Гость
« Ответ #26 : 06-05-2004 04:48 » 

я уже почти разобрался, просто я залил движок на шапку, а т.к. я в линухе почти не волоку возникали трудности. Счас как раз ковыряюсь с этим делом, если будут вопросы, задам. А траблы были детские: сначала стоял php собраный без --with_mysql, потом парился с запуском самого mysql, потом в mysql добавил юзера. Счас парюсь с администрированием, что-то нелогинит меня админом на сайт, говорит "Hacers".
Записан
Гром
Птычк. Тьфу, птычник... Вот!
Готовлюсь к пенсии

il
Offline Offline
Пол: Мужской
Бодрый птах


« Ответ #27 : 06-05-2004 05:27 » 

Kuzmich, разреши куки...
Кроме того - ты будешь хакером если не нажал Выход, защита ептыть Улыбаюсь

Для входа с администрированием надо было тебе изначально ввести юзера, а потом если есть проблема - смотри работу куки!!!!
Записан

А птичку нашу прошу не обижать!!!
Kuzmich
Гость
« Ответ #28 : 06-05-2004 09:46 » 

хммм.... странно я тут пост постил про куки, видел его собственными глазами, а сейчас его нет Жаль
Признавайтесь кто удалил  :l_happy:
Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #29 : 06-05-2004 10:11 » 

Kuzmich, видимо глюк... А не мог ты его сам удалить?
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Страниц: [1] 2  Все   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines