ExBB Community ExBB Community
 Сайт проекта ExBB Общение объединяет!
Войдите на форум при помощиВойти через loginza
 Чат на форуме      Помощь      Поиск      Пользователи     BanList BanList

Страниц (51): « 1 2 3 [4] 5 6 7 8 9 ... » В конец

> Найдено сообщений: 762
1Bot Отправлено: 10 сентября 2018 — 21:19 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 31438
Чтобы было проще работать с любой из версий, необходимо:

1) декомпозиция по функциональному признаку всех уже существующих данных, свойств и методов их обработки со словесным описанием "доменов" (формирование основных классов, их данных и методов);

2) выделение взаимосвязей "доменов" и словесное описание их характера взаимодействия (создание интерфейсов между классами);

3) описание базовых "доменов" для хранения данных;

4) описание целей и критичности взаимодействия.

Flat , Вы сейчас пробуете свои силы на 3 и 4 этапах, без полного прохождения 1 и 2. Уверена, что это потребует больше сил и мыслительной энергии, чем естественный путь.
1Bot Отправлено: 15 августа 2018 — 15:51 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 31438
Flat, как Ваши успехи с файлами прямого доступа?
1Bot Отправлено: 9 августа 2018 — 08:07 • Тема: Создание API форума ExBB • Форум: Обсуждаем

Ответов: 2
Просмотров: 2863
Flat пишет:
АПИ должны быть у каждого модуля свои. Например модуль "меню". У него есть свои АПИ типа "добавить новый пункт", "удалить существующий", "изменить порядок" и т.д.

Верно, сейчас API очень легко обобщить как передачу определенных GET, POST запросов самому форуму от лица определенного пользователя.
1Bot Отправлено: 27 июля 2018 — 15:27 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 31438
Удаленные записи/части записей лучше помечать как удаленные, фактически оставляя удаленные блоки без изменений.

Реальную очистку производить по запросу VACUUM (в СУБД так и происходит).

При редактировании записи с текстом, если длина не увеличилась, то перезаписать на то же место, если увеличилась, то пометить текущую запись как удаленную и записать новую запись в конец файла.
Если это последняя запись в файле, то также переписываем.

Произвольную структуру в записи можно хранить в виде текста (использовать сериализацию или json).
1Bot Отправлено: 27 июля 2018 — 13:47 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 31438
Flat ,
С записями одинаковой структуры это замечательно. Есть вопрос как хранить структуры с переменным числом полей, наподобие ассоциативных массивов?

Еще вопрос - как редактировать/удалять записи из такой структуры?
1Bot Отправлено: 27 июля 2018 — 12:35 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 31438
Flat пишет:
Сейчас популярно обьясню))
Например имеем такую базу данных, в которой каждая строка это одна запись, а отдельные поля записи отделены каким-либо редко используемым знаком. Зачастую для этой цели используется знак |(вертикальная черта):
0000001| admin|password|ad@kuku.com|ad
0000002| masha|password|gg@zuzu.com|me
0000003|grisha|password|ff@bubu.com|me
и т.д
Естественно, что вертикальную черту в текстах необходимо заменить на html сущности.
Каждое поле имеет определённую длину, которая прописана в скрипте, а общая длина записи постоянна.
Чтобы получить отдельную запись или отдельное поле при прямом доступе, ненужно качать всю базу в память, а необходимо, просто напросто, подвести считывающую головку(виртуальную, ибо сейчас уже используют твёрдотельные накопители) непосредственно к записи и считать её в память. Делается это очень просто.


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

Для текстовых данных это едва ли возможно без чрезмерных затрат места.

Flat пишет:
Я нашёл простое решение, которое позволяет отказаться от индексных файлов. Вот в чём дело. Это намного упрощает базу и работу с ней без потерь эффективности.
...
Вчера доработал функцию бинарного поиска и сделал обёрточную функцию. Так что дело идёт полным ходом, Следите за новостями


Алгоритмы бинарного поиска используются и при использовании индексов СУБД (там используют Б-деревья для поиска). Сам алгоритм берет начало в 197х годах.

Если получится что-то эффективнее - то только на специфических данных.
1Bot Отправлено: 26 июля 2018 — 20:20 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 31438
Flat пишет:
Проверял скорость на прямом переборе потому, что это будет необходимо при удалении и редактировании записей. Создал базу из записей по 156 байтов, записей 100 000, вес базы 15 мегабайт с лишним. Так вот, скорость поиска последнего элемента такой базы составила 0,2 секунды. База в 1 миллион записей будет иметь скорость 2 сек. Это в 2 раза меньше, чем качать всю базу в память посредством функции file, а потом разбивать её при помощи explode.
Затем протестировал бинарный поиск по такой базе, при помощи моей функции бинарного поиска:
...
, и оказалось , что скорость увеличилась где-то в 500 раз.. То есть не 0,2 сек., а 0,2/500 = тут сами подсчитайте на калькуляторе сколько это будет: просто один миг.. То есть поиск по миллионной базе займёт доли секунды..
Эта функция тоже тестовая и будет переделана.


Приведу для сравнения примеры выборок из таблицы СУБД mysql c 2 242 208 записями (общим размером 2 ГБ), где каждая запись состоит из 47 полей

CODE:
CREATE TABLE `updated` (
`ID` INT(15) UNSIGNED NOT NULL AUTO_INCREMENT,
`Title` VARCHAR(2000) NULL DEFAULT '',
`VolumeInfo` VARCHAR(100) NULL DEFAULT '',
`Series` VARCHAR(300) NULL DEFAULT '',
`Periodical` VARCHAR(200) NULL DEFAULT '',
`Author` VARCHAR(1000) NULL DEFAULT '',
`Year` VARCHAR(14) NULL DEFAULT '',
`Edition` VARCHAR(60) NULL DEFAULT '',
`Publisher` VARCHAR(400) NULL DEFAULT '',
`City` VARCHAR(100) NULL DEFAULT '',
`Pages` VARCHAR(100) NULL DEFAULT '',
`PagesInFile` INT(10) UNSIGNED NOT NULL DEFAULT '0',
`Language` VARCHAR(150) NULL DEFAULT '',
`Topic` VARCHAR(500) NULL DEFAULT '',
`Library` VARCHAR(50) NULL DEFAULT '',
`Issue` VARCHAR(100) NULL DEFAULT '',
`Identifier` VARCHAR(300) NULL DEFAULT '',
`ISSN` VARCHAR(9) NULL DEFAULT '',
`ASIN` VARCHAR(200) NULL DEFAULT '',
`UDC` VARCHAR(200) NULL DEFAULT '',
`LBC` VARCHAR(200) NULL DEFAULT '',
`DDC` VARCHAR(45) NULL DEFAULT '',
`LCC` VARCHAR(45) NULL DEFAULT '',
`Doi` VARCHAR(45) NULL DEFAULT '',
`Googlebookid` VARCHAR(45) NULL DEFAULT '',
`OpenLibraryID` VARCHAR(200) NULL DEFAULT '',
`Commentary` VARCHAR(10000) NULL DEFAULT '',
`DPI` INT(6) UNSIGNED NULL DEFAULT '0',
`Color` VARCHAR(1) NULL DEFAULT '',
`Cleaned` VARCHAR(1) NULL DEFAULT '',
`Orientation` VARCHAR(1) NULL DEFAULT '',
`Paginated` VARCHAR(1) NULL DEFAULT '',
`Scanned` VARCHAR(1) NULL DEFAULT '',
`Bookmarked` VARCHAR(1) NULL DEFAULT '',
`Searchable` VARCHAR(1) NULL DEFAULT '',
`Filesize` BIGINT(20) UNSIGNED NOT NULL DEFAULT '0',
`Extension` VARCHAR(50) NULL DEFAULT '',
`MD5` CHAR(32) NULL DEFAULT '',
`Generic` CHAR(32) NULL DEFAULT '',
`Visible` CHAR(3) NULL DEFAULT '',
`Locator` VARCHAR(733) NULL DEFAULT '',
`Local` INT(10) UNSIGNED NULL DEFAULT '0',
`TimeAdded` TIMESTAMP NOT NULL DEFAULT '2000-01-01 07:00:00',
`TimeLastModified` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`Coverurl` VARCHAR(200) NULL DEFAULT '',
`Tags` VARCHAR(500) NULL DEFAULT '',
`IdentifierWODash` VARCHAR(300) NULL DEFAULT '',
PRIMARY KEY (`ID`),
UNIQUE INDEX `MD5` (`MD5`),
INDEX `Generic` (`Generic`) USING BTREE,
INDEX `VisibleTimeAdded` (`Visible`, `TimeAdded`) USING BTREE,
INDEX `TimeAdded` (`TimeAdded`) USING BTREE,
INDEX `Topic` (`Topic`(3)) USING BTREE,
INDEX `VisibleID` (`Visible`, `ID`) USING BTREE,
INDEX `VisibleTimeLastModified` (`Visible`, `TimeLastModified`, `ID`) USING BTREE,
INDEX `TimeLastModifiedID` (`TimeLastModified`, `ID`) USING BTREE,
INDEX `DOI_INDEX` (`Doi`) USING BTREE,
INDEX `Identifier` (`Identifier`),
FULLTEXT INDEX `Title` (`Title`),
FULLTEXT INDEX `Author` (`Author`),
FULLTEXT INDEX `Language` (`Language`),
FULLTEXT INDEX `Extension` (`Extension`),
FULLTEXT INDEX `Publisher` (`Publisher`),
FULLTEXT INDEX `Series` (`Series`),
FULLTEXT INDEX `Year` (`Year`),
FULLTEXT INDEX `Title1` (`Title`, `Author`, `Series`, `Publisher`, `Year`, `Periodical`, `VolumeInfo`),
FULLTEXT INDEX `Tags` (`Tags`),
FULLTEXT INDEX `Identifierfulltext` (`IdentifierWODash`)
)
COLLATE='utf8_general_ci'
ENGINE=MyISAM
AUTO_INCREMENT=2242208;


CODE:
select distinct `Year` from `updated` order by `Year` asc;
/* Affected rows: 0 Найденные строки: 3 411 Длительность 1 query: 00:01:22 */

select distinct `Publisher` from `updated` order by `Publisher` asc;
/* Affected rows: 0 Найденные строки: 117 782 Длительность 1 query: 00:01:37 (+ 1,139 sec. network) */

select distinct `Language` from `updated` order by `Language` asc;
/* Affected rows: 0 Найденные строки: 2 202 Длительность 1 query: 47,845 sec. */

select distinct `Library` from `updated` order by `Library` asc;
/* Affected rows: 0 Найденные строки: 563 Длительность 1 query: 45,162 sec. */

select * from updated where ID = 2000000;
/* Affected rows: 0 Найденные строки: 1 Предупреждения: 0 Длительность 1 query: 0,749 sec. */


Просто попробуйте выполнить похожие операции на файлах прямого доступа для сравнения затрат времени
1Bot Отправлено: 26 июля 2018 — 19:59 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 31438
Что сказать, сами придумываем велосипеды, которые уже давно ездят в существующих СУБД.

Экскурс в историю баз данных и их проектирования (чтобы не выдумывать велосипеды)
Экскурс посвящен внутренней структуре реляционных баз данных

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

Ключ — это комбинация нескольких полей, данные в которых однозначно определяют запись Таблицы.
Ключи бывают простыми и сложными (составными).

Простой ключ — это ключ, состоящий из одного поля.

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

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

Ключ иногда называют первичным ключом или главным индексом.

Для чего же служит ключ? Прежде всего, для обеспечения однозначного определения записей таблицы.
Кроме того, ключ предназначен для более быстрого выполнения запросов к базе данных.
По ключевым полям организуется связь между таблицами базы данных.
У ключа есть еще много других функций, они будут объясняться по мере изложения.

Сведения о ключе таблицы могут храниться как вместе с данными таблицы, так и в отдельном файле.
Этот файл имеет такое же имя, что и файл таблицы, но другое расширение.
Например, в базе данных Microsoft Access информация о ключе содержится вместе с данными в одном файле, который имеет расширение .MDB.
А Paradox выделяет для информации о ключе отдельный файл с расширением .РХ.

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

Ключевые поля вам придется определять самостоятельно, поэтому следуйте представ­ленным ниже правилам, которые помогут достаточно эффективно выбрать эти поля:

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


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

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

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

Поля, по которым строится индекс, называют индексными полями.
Процесс создания индекса называется индексированием таблицы.

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

В отличие от ключа, который является уникальным в каждой таблице, индексов в ней может быть несколько.
Это в первую очередь необходимо для быстрой сортировки по нужному полю или полям.
Если эти поля проиндексированы, то сортировка по ним будет выполнена значительно быстрее, чем по обычным полям.
В любой момент времени можно активировать любой из индексов таблицы.
Именно по активному (текущему) индексу обычно будет выполняться сортировка записей таблицы.
Следует, однако, заметить, что, несмотря на наличие нескольких индексов, таблица может не иметь текущего индекса.

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

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

ВНИМАНИЕ: Процесс создания ключа в ряде случаев может привести к неожиданным результатам.
Например, при создании ключа в таблице базы данных Paradox будут автоматически отсортированы записи по значениям ключа.
1Bot Отправлено: 24 июля 2018 — 20:03 • Тема: MYSQL related issue ?? • Форум: MySQL

Ответов: 1
Просмотров: 3465
Hi, BenjaminJohnson

You can find a answer for your question to log of your web server.
1Bot Отправлено: 10 июля 2018 — 23:03 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 31438
Flat, рассуждая об ООП не забывайте, что основной код был написан еще для PHP4 и лишь немного видоизменен для работы с PHP5 на уровне "чтобы не возникало фатальных ошибок и предупреждений". Используется практически только один класс fm, хотя у меня от него стойкая ассоциация с микросервисом со своим апи.

Сейчас же есть возможности как раз использовать средства ООП из новых версий PHP7 и по возможности убирать таким образом функциональные повторы в существующем коде.
Так что полный отказ от ООП будет скорее ошибкой.

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

До сих пор сложно разрабатывать модули (нет описания интерфейсов взаимодействия ядра и модуля, тут полиморфизм ООП был бы очень кстати), чтобы их было легко интегрировать в админку и в основной форум.
1Bot Отправлено: 10 июля 2018 — 22:22 • Тема: Доработки и исправления в ExBB • Форум: Обсуждаем

Ответов: 79
Просмотров: 31438
Yamaliya пишет:
по структуре данных. Надо бы предусмотреть конвертер туда и обратно.

Проще сразу в функции класса для чтения такой структуры делать проверку что в начале файла <?die;?> или <?php die;?>
и независимо от того правильно считывать, тогда в функции сохранения можно использовать любой из этих форматов данных.
1Bot Отправлено: 24 марта 2018 — 19:11 • Тема: Проблема с http - s • Форум: Решение проблем

Ответов: 8
Просмотров: 5040
NordWest пишет:
В коде учитываются ссылки вида www которые судя по коду подменяются на http

Думаю лучше будет вообще убрать из url указание протокола.

NordWest пишет:
Ссылки вида www вообще сейчас кто-то использует или это атавизм?

атавизм, но иногда нет редиректа с www на домен без www.
1Bot Отправлено: 24 марта 2018 — 18:40 • Тема: Косметические доработки форума • Форум: Настройка форума

Ответов: 222
Просмотров: 151021
electron пишет:
все файлы перерыл, хз где этот br вставляется....

смотреть функцию nl2br()
именно она выполняется для поста после всех преобразований bb-кодов.
1Bot Отправлено: 24 марта 2018 — 17:29 • Тема: Проблема с http - s • Форум: Решение проблем

Ответов: 8
Просмотров: 5040
Yamaliya , проблема в недоступности картинки по ссылке, т.к. https в ссылке на изображение допустим.
(Добавление)
пример

Проблема в более ранних версиях не наблюдалась
(Добавление)
Скорее всего это защита от внешних ссылок работает
(Добавление)
проба со ссылкой на тоже изображение, но без s

(Добавление)
так и есть
1Bot Отправлено: 14 января 2018 — 19:43 • Тема: Решение проблем с Sqlite • Форум: Решение проблем

Ответов: 4
Просмотров: 2136
NordWest , для других linux based будет что-то аналогичное, скорее всего только пакетный менеджер будет отличаться.

Страниц (51): « 1 2 3 [4] 5 6 7 8 9 ... » В конец

Яндекс.Метрика   

Powered by ExBB
ExBB FM 1.0 RC1 by TvoyWeb.ru
InvisionExBB Style converted by Markus®

[Script Execution time: 0.0356]     [ ]