Программистам Delphi - Страница 6

Dian · 05.01.2006, 17:46

Думаешь это поможет делу?

Shah · 14.01.2006, 16:29

Давно не заглядывал...
Идея отличная! Но... чем дальше в лес, тем больше дров. Насчет онлайн полностью согласен с PHP+MySQL!!!!! В офлайне бардак, честное слово. Далеко не все могут (да и не захотят) устанавливать у себя какие-либо системы баз данных. Думаю, есть и такие, у которых нет даже акцеса. К тому же городить огород наверное не стоит. На мой взгляд самый идеальный вариант, когда клиент БД скачает в XML.
Прежде ввсего надо создать структуру БД.
Могу помочь PHP, MySQL, HTML, Delphi.

Talisman · 14.01.2006, 16:39

когда начнем? кто первый?
(помогу с: php,perl,mysql,html,css)
Предлагаю: создать группу юзеров, и спец форум открыть для этого.

Зирк · 14.01.2006, 16:42

А какой смысл от группы юзеров? Хотя спецфорум........
Может и не помешает.
Помогу чем смогу, как уже и говорил, но организации нет никакой, тк что никакого толку от всей помощи нет, к сожалению.
Кто возьмёт в стальную лапу кучу программистов?

Shah · 14.01.2006, 16:43

Согласен. Исключительно для обсуждения деталей и согласования действий и т.д.

Talisman · 14.01.2006, 17:07

Предлагаю за основу взять движок форума phpBB2.0.19 - самая новая версия. к тому же на этом портале тоже стоит phpBB, поверх форума повесить самописный модуль(который собственно и надо написать), который будет организовывать удобное добавление и редактирование статей (я считаю, что из существующих никакой готовый движок это нормально не делает), и каждой статье создается обсуждение (на это и нужен phpBB2). все наши действия будут абсолютно законными! (выбран именно phpBB так как в новых версиях дырок еще не нашли

Какие будут прибамбасы? это уже другой разговор

можно зделать динамическую флеш микс версию, чтоб курче смотрелось

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

ну и в третьих: существуют подобные системы, но они либо только онлайновые, либо только оффлайновые, а наша будет и такой и такой

т.е. раз в неделю (а то и чаще) будут происходить обновления оффлайновой версии
2 all: ну как идея? какие дополнения/изменения?
2 Алексеев Николай, Garik, админы: Когда начнем? возьмете узды правления?

Dian · 14.01.2006, 19:22

Цитата:

Originally posted by Talisman
[b]раз в неделю (а то и чаще) будут происходить обновления оффлайновой версии

А почему не по запросу клиента?

andrey_pst · 16.01.2006, 19:10

Насчет данных в XML - идея, на мой взгляд, неплохая.

Появляется ряд вопросов:
1. Как хранить данные в серверной версии? Тоже в XML-файлах или в БД или в XML в БД (надеюсь понятно выразился)? В идеале, на мой взгляд, организовать хранение одинаковым способом и на сервере и у клиентов.

Первый вопрос тянет за собой еще:

2. Как обновлять локальные данные? Объем обновлений должен быть как можно меньше. Нужно как-то идентифицировать данные - обновленные они или нет - в случае без БД это можно делать вычисляя CRC (MD5). А из БД? Как клиент будет получать обносления? В случай с файлом - просто скачать, а в случае с БД? Выбрать данные, сформировать из них новый XML файл и сохранить его? Или Выбранные данные и будут уже готовым XML файлом, который нужно только сохранить?

3. Как изменять данные на сервере? В файл можно что-либо дописать. А в БД? Выбрать, изменить, обновить. Не слишком сложно?

4. Кто будет это (п.3) делать? Если дать доступ всем, то чтобы напихать в БД всякого спама необходимо будет только зарегистрироваться на сервере...

У кого какие мнения по вышесказанному?
Я лично предлагаю отказаться от БД в пользу XML файлов.

Зирк · 16.01.2006, 19:42

Как насчёт txt?

andrey_pst · 16.01.2006, 22:55

Цитата:

Originally posted by Зирк
[b]Как насчёт txt?

дык XML и есть txt только с четкой структурой

Shah · 16.01.2006, 22:56

2 andrey_pst
Отвечаю на вопросы:
1. На сервере данные хранятся БЕЗ ВСЯКИХ сомнений в БД MySQL. Это огромная гибкость! Далее я выложу структуру БД.
2. Обновление клиента будет происходит следующим образом: на сервере будет скрипт, отвечающий за преобразование БД в ХМЛ.
Клиент этому скрипту отправит запрос, указав в запросной части дату последнего обновления и (желательно) версию клиента. Это на случай, если клиент будет меняться из версии к версии. Скрипт на сервере сделает выборку из всех таблиц БД по дате последнего обновления и будет высылать клиенту в формате ХМЛ. Клиент получая данные соответственно обновляет свою БД в формате ХМЛ. Этот момент надо получше проработать. А отдельное хранение оффлайн версии БД на сервере это: (1) не эффиктивно, (2) не экономно, (3) нет гарантии, что админ вовремя архивирует и выложит данные.
3. Думаю, на этот вопрос даст ответ мое следующее сообщение. Там выложу предварительную структуру БД. Вставление данных происходит не просто, а очень просто! Юзер вводит данные, скрипт вставляет в БД. И никакой выборки, изменения и обновления.
А при просмотре скрипт выбирает нужное, складывает вместе и выводит в браузер. И все...
4. Опять таки по структуре увидишь, что данные в БД вставляет только регинные юзеры.

От БД невозможно отказаться! Представь себе этот форум в файлах!!! Сам Всевышный ногу сломал бы в чертовой куче файлов.

)

Shah · 16.01.2006, 23:03

За это время никто ничего серьезно и не предложил. Ниже предлагаю предварительную версию БД на обсуждение.

Код:

ER-диаграмма базы данных (структура БД)
_______________
|    USER     |
|-------------|
|USER_ID (PK) |1  создает
|USER_LOGIN   |----------------                
|USER_PSWD    |   запись      |
|USER_REGDATE |               |
|USER_LASTDATE|               |M
|USER_COUNT   |           ____+_______
---------------          /PUBLIC_DATE 
                         |------------|
                         |PD_ID (PK)  |
   запись о компонентах,1|PD_DATE     |1  запись о
      -------------------|USER_ID     |-------------
      |классах, типах    |PD_TYPE     |   методах  |
      |                  |PD_TOPIC(FK)|            |
      |                  PD_DESCR    /            |
      |                   ------------             |
      |   родитель            1|  запись           |
      |  -----------|          ---о свойствах      |
     M| M|          |           M|                 |
______+__+_______ 1 |      ______+_______          |
|   COMPONENT   |---|      |  PROPERTY  |          |
|---------------|          |------------|          |
|COMP_ID (PK)   |компонент |PROP_ID (PK)|          |
|COMP_NAME      |содержит  |PROP_NAME   |          |
|COMP_TYPE      |---------+|PROP_TYPE   |          |
|COMP_PARENT(FK)|свойтво   |COMP_ID (FK)|          |
-----------------          --------------          |
       |1                                          |
       |                                           |
       |                                           |M
       |                                     ______+_______
       |                                     |   METHOD   |
       |                                     |------------|
       |                                     |MTD_ID (PK) |
       |      компонент содержит метод      M|MTD_NAME    |
       -------------------------------------+|MTD_ROUT_T  |
                                             |MTD_TYPE    |
                                             |COMP_ID (FK)|
                                             --------------

USER - таблица регистрированных пользователей
PUBLIC_DATE - составная таблица между таблицей USER и
таблицами COMPONENT,PROPERTY,METHOD
COMPONENT - таблица компонентов
PROPERTY - таблица свойств объекта
METHOD - таблица методов объекта
(PK) - означает первичный ключ таблицы (Primary key)
(FK) - означает внешний ключ (Foreign key)
------------------------------------------------------------
Все вставляемые данные будут храниться в таблице PUBLIC_DATE.
Это позволит вставлять в описание одного и того же класса, свойства,
метода множества описаний,добавлений, изменений. К тому же эта таблица
ведет учет по дате и времени кто, когда и что добавлял. Программа
находит все записи относящиеся к требуемому объекту и выводит их в одном окне
с указанием автора (если необходимо и даты добавления) информации.
Поле COMP_PARENT в таблице COMPONENT ссылается на COMP_ID своей же таблицы, указывая
тем самым на родительский класс.
ПОле PD_TYPE в таблице PUBLIC_DATE может иметь значения COMPONENT,PROPERTY,METHOD.
Определяя таблицу, к которой надо обращаться. Ссылка хранится в поле PD_TOPIC.
Этим исключается пустые поля, если б хранили 3 внешних ключа. К тому же могут
добавиться и другие описательные таблицы, например события (EVENT). Тогда в домен
значений поля PD_TYPE добавим всего одно значение EVENT и функцию обработки этого
значения в скрипт. (Кстати, я на самом деле забыл про таблицу EVENT)
---------------------------------------------------------------------------------
Буду рад выслушать все замечания, предложения и пожелания

)

andrey_pst · 17.01.2006, 19:38

Можно поподробнее о:
1. связи между таблицей COMPONENT и таблицей PUBLIC_DATE
2. связи между таблицей PROPERTY и таблицей PUBLIC_DATE
3. связи между таблицей METHOD и таблицей PUBLIC_DATE
4. у вторичного ключа PD_TOPIC внешняя таблица какая? а поле во внешней таблице?
5. Правила у вторичных ключей какие (при обновлении, при удалении)?

Также неплохо было бы узнать описания полей и их типы данных во всех таблицах.

Shah · 17.01.2006, 23:35

2 andrey_pst[list]
* Поставлена задача: Иметь в интернете некую базу данных компонентов Дельфи, куда люди могли бы вносить свои находки по свойствам, методам компонента. То есть какие значения каким результатам приведет и т.д.
* Цели: Для выполнения данной задачи было предложено использовать связку PHP-MySQL. Данные хранить в базах данных.
* Проект базы: выше я предложил первоначальную структуру базы, которая на мой взгляд наиболее полной мере отвечает требованиям поставленной задачи.[list]
Чтоб ответить на вопросы 1-4 приведу пример: допустим в табл. COMPONENT имеем некий компонент. В таблице PROPERTY имеем несколько свойств этого компонента. Как известно в таблицах данные должны встречаться единожды. А в описание свойства могут вносить изменения десятки человек (раз). Варианты: 1) сделать как ты предположил: выборка, изменение, обновление или 2) создавать несколько (много) записей для одного и того же свойства. Как видно оба метода не эффиктивно. Есть еще третий путь: создать 3 дополнительных таблиц для каждой таюлицы компонентов, свойств или методов (еще и для событий). Тут уже получается некоторая избыточность данных на уровне базы по полям USER_ID, PD_TOPIC и т.д.
Я предложил другой вариант: все описания по всем таблицам хранить в одной таблице. То есть в нарушение правил проектирования БД одно поле (PD_TOPIC) ссылается сразу нескольким таблицам, но в пределах каждой записи ссылается только на одну запись одной таблицы. За этим следить поле PD_TYPE. Пример:

Код:

В таблице PUBLIC_DATE:
PD_ID  PD_DATE  USER_ID  PD_TYPE  PD_TOPIC  PD_DESCR
--------------------------------------------------------------------------
1001   17.01.06  34      PROPERTY   1202    Описание свойства
1002   17.01.06  26      METHOD     121     Описание метода

Созданы 2 записи 1001 и 1002 пользователями 34 и 26 для свойства и метода, хранящихся в таблицах PROPERTY и METHOD под номерами 1202 и 121. Таким образом поле PD_TOPIC ссылается только на таблицу, значение которой приведен в поле PD_TYPE.
PD_TOPIC ссылается или на поле COMP_ID таблицы COMPONENT или на поле PROP_ID таблицы PROPERTY или MTD_ID таблицы METHOD. Программа обрабатывает значение PD_TYPE и принимает решение на обработку таблиц.
Все поля с окончанием ID имеет тип AUTONUMBER. Обновление запрещено. Правила связей:[list]
* связь между таблицами USER и PUBLIC_DATE: Обновление запрещено, удаление запрещено.
* связи PROPERTY-COMPONENT и METHOD-COMPONENT: Обновление запрещено, удаление запрещено.
* связь поля COMP_PARENT на поле COMP_ID таблицы COMPONENT: Обновление запрещено, при удалении связанной записи поле COMP_PARENT должно обнуляться. То есть компонент без родителя может существовать.
* связь между таблицей PUBLIC_DATE и таблицами COMPONENT,PROPERTY, METHOD: Обновление запрещено, удаление запрещено.[list]
Удаление запрещено означает, что пока на данную запись ссылается хоть одна другая запись, запись не может быть удалена.
Информацию по типам и описаниям полей в другой раз. К тому же сейчас это не самое главное, главное, если проекту суждено жить, то определить костяк, на который будет навещиваться мясо.

PS. Предлагаю название проекта: "FAQ по компонентам Delphi". Рабочее название: comfaq

Dian · 18.01.2006, 06:31

Shah
Действительно ли нам нужны отдельные таблицы для свойств/методов/событий? Таблицы накручивают сложность БД, усложнят выборку, а заодно лишат нас возможности контроля целостности средствами субд

Опции темы
Версия для печати Отправить по электронной почте
Опции просмотра
Линейный вид Комбинированный вид Древовидный вид

Похожие темы
Тема	Автор	Раздел	Ответов	Последнее сообщение
Вопрос программистам.	I1_Sidelnik	Вопросы начинающих программистов	78	31.01.2012 18:54
работа программистам	алексей 35	Работа	1	31.05.2011 16:34
Переход с Delphi 5 на Delphi 7	ГС ТОФ	Delphi	3	02.10.2008 22:17
Работа программистам в Париже	Nova Consulting	Работа	2	25.07.2006 16:41
Как в Delphi 7 сделать чтоб при запуске Delphi автоматически не создавался проект1	Deos	Delphi	8	17.04.2006 16:27
Как перевести код Си на Delphi , dll в С++ и в Delphi	Samurai	Delphi	0	26.02.2006 14:58
Разница Delphi 6 и Delphi 7	imported_Logan	Delphi	16	05.08.2004 00:30
Программистам посвящается	Ex	Юмор	1	01.08.2004 00:49
Exel и Delphi. Как передать данные из Delphi в Excel	Morfey	Delphi	1	08.06.2004 18:52
Delphi и Excel как в Delphi определить присвоено ли имя выделенной области	Bairum	Delphi	1	01.05.2004 12:14
Как открыть приложение Delphi 7 в Delphi 5	imported_Карен	Delphi	2	19.03.2004 17:50
Предложение программистам размещение рекламы	Anonymous	Некоммерческие проекты	10	10.03.2004 01:05

Dian Member Сообщений: 5,243 Сказал(а) спасибо: 0 Поблагодарили 0 раз(а) в 0 сообщениях Регистрация: 17.09.2004	05.01.2006, 17:46 Думаешь это поможет делу?

Talisman Member Сообщений: 282 Сказал(а) спасибо: 0 Поблагодарили 0 раз(а) в 0 сообщениях Регистрация: 02.12.2005	14.01.2006, 16:39 когда начнем? кто первый? (помогу с: php,perl,mysql,html,css) Предлагаю: создать группу юзеров, и спец форум открыть для этого.

Shah Member Сообщений: 212 Сказал(а) спасибо: 0 Поблагодарили 0 раз(а) в 0 сообщениях Регистрация: 02.08.2003	14.01.2006, 16:43 Согласен. Исключительно для обсуждения деталей и согласования действий и т.д.

Зирк Member Сообщений: 1,337 Сказал(а) спасибо: 0 Поблагодарили 0 раз(а) в 0 сообщениях Регистрация: 14.04.2005	16.01.2006, 19:42 Как насчёт txt?

Dian Member Сообщений: 5,243 Сказал(а) спасибо: 0 Поблагодарили 0 раз(а) в 0 сообщениях Регистрация: 17.09.2004	18.01.2006, 06:31 Shah Действительно ли нам нужны отдельные таблицы для свойств/методов/событий? Таблицы накручивают сложность БД, усложнят выборку, а заодно лишат нас возможности контроля целостности средствами субд

Ads