MaHarder

@celsoft мне было интересно решение относительно такой структуры. ни я, ни кто-либо другой не может вам что либо навязать. Однако, загорелся интерес проверить затрату времени при выборке данных полей дат. Я использовал базу данных сотрудников своей фирмы, само собой - её копию, а именно таблицу по рабочим часам. Для теста я взял данные за 2018 год. Сначала я запрашивал как datetime, а затем как varchar. Integer не трогал. Всего собралось более 36000 строк. Думаю, этого будет достаточно. Тест показал, что конвертация дат из текста, куда больше времени и ресурсов занимает, нежели конвертация из даты в текст. Может, я что-то упустил или напутал. Кто знает. Вот, сам тест. И да, я тестировал на PostgreSQL. Если вам так угодна скорость и работоспособность базы данных, то почему же не использовать SQLite? Она идеально подходит вашим требованиям, даже лучше. На вебхосте даже не нужно иметь отдельно базы данных. И взаимодействие будет происходить куда быстрее и эфективнее. То, что ваши 15000 клиентов сидят на MyISAM - ничего страшного, обновят в ходе обновления движка. А те, кто не сидит на актуальных версиях - обновлять не будет и их это ну никак не коснётся. Тем более, что минимальное требование по MySQL значится как 5.5.3. Рано или поздно вам всёравно придётся обновляться. А с версии 5.5.6 InnoDB уже стандартный движок MySQL. Конечно, опыт с хостерами у нас разный, но на моём опыте - пока никто из хостеров не отказывал в апгрейде MySQL, ибо им это не выгодно. Да, у вас в CMS системах больше опыта, чем у меня, поскольку я работаю с ERP-системами. Спасибо, ответ на свои вопросы я получил. Повторюсь в очередной раз, никому и ничего я не хотел и не хочу навязывать.

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

Причём тут фреймворк до 3. нормы базы данных? я вам о Foreign Keys говорю. Я ради наглядности сделал пару связок: Ведь проще удалить, к примеру, одну новость со всеми логами, комментариями, файлами и т.д. ОДНИМ запросом, нежели n запросами, поскольку таблицы будут связаны друг с другом. Это функционал самой базы данных, а не DLE. И я понимаю, что для этого нужно будет принудительно обновить базу данных до InnoDB. Думаю, это не проблема. С UTF-8 тоже ведь получилось. Ну, вы сами говорите, что не стоит утверждать то, что не знаете. У нас преподователи хорошо получают, больше чем в больших/крупных компаниях. Чем она занималась во время работы на свободном рынке - не вам осуждать. По программе обучения IHK считается, что быстродействие и реакция между таблицами наилучше всего достигается при нормализации единообразных названий начиная со второй нормы. Не мне вас судить, если учесть, что даже в Deutsche Bahn бардак с базой данных, то там и уровень разработки выше. Простите, вы имеете опыт работы в Data Warehouse? Моя училка - имеет. Но, это не имеет значения, я лишь хотел преукрасить ситуацию с базой данных. Не думал, что вы так зациклитесь на ней. Я хотел лишь указать на не систематические названия и структуру. Не сомневайтесь, создам. А покажу - будет зависеть от работодателя. Однако я не считаю выборку, хотябы тех же доп. полей, производительной частью. проще достать и получить массив при помощи select xf.name, xf.alt_name from xfields xf, post_xfields px where xf.id = px.xfield and news_id = 1 $result = $mysqli->query($query); $xfields = $result->fetch_array(MYSQLI_ASSOC); нежели select xfields from dle_post where id = 1 $result = $mysqli->query($query); $xfields_row = explode('||', $result['xfields']); $xfields = array(); foreach($xfields_row as $xr) { $xTemp = explode('|', $xr); $xfields[$xTemp[0]] = $xfields[$xTemp[1]]; } А если поле изменится, то, на данный момент, нужно исправлять это через поиск и замену в базе данных. Очень удобно и производительно. Решать вам. тогда, может сразу всё в текстовом формате сохранять? Ведь конвертировать даты можно и при помощи функции convert, date и т.д. в базе данных. Это же сколько сэкономит на производительности? Я извиняюсь за свои придирки и, наверное, насмешки, не мне решать как развивать движок далее. Ведь, сторонним разработчикам будет проще разрабатывать для DLE на таких простых структурах. И всё же, один вопрос остаётся открытым ибо аналогичные ему - имеют 6ти значное число ========================== Я ничего не хочу навязывать. Мне было интересно, почему такая структура, будет ли она изменена. Каждый учился по своему и у каждого своя "библия" по написанию кода. Да, я видел структуры базы данных похуже, та же система ERP Odoo - сплошной кошмар, к примеру.

значит ли это, что лид команды спустил всё на тормозах, @celsoft? ладно названия, ещё куда не шло, но типы поля - это жесть. к тому же пользователя идентифицируют то по имени, то по айди - надо же как-то определиться уже... я бы вообще dle_post разделил бы на 4 таблицы. категории уже существуют, посему ещё нужны доп. поля и похожие новости. такое чувство, что о нормативах базы данных никто не слышал ничего и постепенно разрабы осваивают википедию или мануалы... моя училка по базам данных наверное сразу бы коньки откинула увидев такую структуру... очень не удобно работать с таблицами, когда удаляешь ту же новость. давно пора перейти на 3. норму. и желательно на Postgre.

Разрабатывая API заметил, что нет однообразных названий для определённых полей. autor, он же author news_id, он же post_id, p_id, n_id user_id, он же member, u_id descr, он же description Про даты вообще молчу, то string, то integer, то datetime В таблице usergroups проверьте поле max_edit_days. Точно однозначный int? Почему не использовать Foreign keys?

Написал апи на основе slimframework 3. Однако, нужны добровольцы в тестировании. Плагин находится здесь: Github Документацию к API начал писать: POSTMAN. Принцип один и тот же для всех таблиц. Предложения можно добавить через feathub Связаться со мной можно через телеграм:@MaHarder Установка через плагины. Подключение к базе данных берётся от конфигурации движка.

@germanydletest, был занят аналогичным проектом. Перевёл website.lng и ещё пару файлов до версии DLE 13.0. Если интересно, то держи: Ссылка

а ты думаешь, сейчас на чём строят сайты? С нуля? Не смеши. В нашей компании берётся симфони или дженго и уже не их основе строится CMS. В других же берут тот же ларавел,кодигнит или зенд.И это только на пхп. на .Net - Entity Framework. Это тупая отговорка. Сейчас куда ни глянь, те же шаблоны, на ту же DLE делаются на основе бутстрапа или другого фреймворка. и за всё это требуют деньги.

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

https://pogugli.com/?344814

https://pogugli.com/?344785 https://dle-news.ru/extras/online/topiccats1.html

что мешает создать "соседний" стиль и подключить его после бутстрапа и прописывать все правки в нём?

Прошёл по нескольким новостям - всё в порядке

не знаю, есть ли, но можно JS $('body').find('a').each(function() { $(this).attr('target', '_blank'); }); тупо все ссылки будут с этим атрибутом. если нужна конкретика, то укажи её вместо тега а или дополни его