MaHarder

@celsoft мне было интересно решение относительно такой структуры. ни я, ни кто-либо другой не может вам что либо навязать. Однако, загорелся интерес проверить затрату времени при выборке данных полей дат. Я использовал базу данных сотрудников своей фирмы, само собой - её копию, а именно таблицу по рабочим часам. Для теста я взял данные за 2018 год. Сначала я запрашивал как datetime, а затем как varchar. Integer не трогал. Всего собралось более 36000 строк. Думаю, этого будет достаточно. Тест показал, что конвертация дат из текста, куда больше времени и ресурсов занимает, нежели конвертаци

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

Причём тут фреймворк до 3. нормы базы данных? я вам о Foreign Keys говорю. Я ради наглядности сделал пару связок: Ведь проще удалить, к примеру, одну новость со всеми логами, комментариями, файлами и т.д. ОДНИМ запросом, нежели n запросами, поскольку таблицы будут связаны друг с другом. Это функционал самой базы данных, а не DLE. И я понимаю, что для этого нужно будет принудительно обновить базу данных до InnoDB. Думаю, это не проблема. С UTF-8 тоже ведь получилось. Ну, вы сами говорите, что не стоит утверждать то, что не знаете. У нас преподователи хорошо получают, б

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

Разрабатывая 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

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

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