Структура базы данных

[MaHarder 20]

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

[webair 178]

2 часа назад, MaHarder сказал:

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

Давно известно и обсуждалось многократно.

Не известно точно, по какой причине так, но вроде @celsoft говорил, что из-за того, что несколько разработчиков. А оставили так для совместимости.

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

[MaHarder 20]

12 часов назад, webair сказал:

что несколько разработчиков

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

 

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

 

очень не удобно работать с таблицами, когда удаляешь ту же новость. давно пора перейти на 3. норму. и желательно на Postgre.

[celsoft 6 072]

4 часа назад, MaHarder сказал:

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

Давайте вы не будете давать советы, понятия при этом не имея почему что то именно так и не иначе. Договорились? Нет никакой определенности. И нет никакой идентификации пользователя то по имени то по id.  Именно идентификация по одному параметру. А в некоторых таблицах есть имя пользователя, чтобы не тянуть эти данные связками и тем самым снизить нагрузку, когда это возможно. А когда нужно более расширенная информация, то используются уже связки по ID.

 

4 часа назад, MaHarder сказал:

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

 Поэтому она и не создавала CMS, которые еще никто не обогнал по самой низкой нагрузке на сервер, при имеющихся в ней функциях. При всех своих знаниях нормативов и пятерок в школе ))

 

4 часа назад, MaHarder сказал:

очень не удобно работать с таблицами, когда удаляешь ту же новость. давно пора перейти на 3. норму. и желательно на Postgre.

Лично DLE и нам удобно. А DLE как известно готовый коробочный продукт, а не фрейворк. Понимаете разницу?

 

4 часа назад, MaHarder сказал:

я бы вообще dle_post разделил бы на 4 таблицы. категории уже существуют, посему ещё нужны доп. поля и похожие новости.

Так создайте свою CMS, потом похвастаетесь, и мы посмотрим на ее производительность. Нет такого понятия, как правильно или неправильно. Есть продукт, который должен выполнять заявленные функции, и при этом делать это должен быстро и качественно. И именно к этому мы стремимся, и более того реализовали. А ваше обучение нормам, не делает продукт более быстрым и менее ресурсоемким, а наоборот. Вы увидели различия в типах, и все, начали думать о своих каких то нормативах, а вот почему именно так и не иначе, что это дает и какие преимущества в производительности, вы никогда не думали.

 

Я при этом не говорю, что DLE абсолютно идеален в плане производительности и в нем наверняка можно что то улучшить и поменять, и такие предложения я с удовольствием готов слушать и реализовывать. Но говорить о непонятно кем установленных нормативах ... суть которых лишь замедлить DLE и увеличить нагрузку, зато чтобы было как в школе учили? Нет уж увольте ...

19 часов назад, MaHarder сказал:

Про даты вообще молчу, то string, то integer, то datetime

И это правильно. Потому как иногда нужно оперировать выборками дат, например по месяцам, и тогда datetime оптимален, потому как в разные месяцы разное количество дней, иногда когда в этом нет необходимости выборка просто по числу намного быстрее потому как integer, а иногда вообще нет выборки по этому параметру и чистый unix формат оптимален, чтобы потом нативно работать с ним в PHP, а как следствие на этом сэкономить ресурсы. Жаль что ваша учительница учила только вас каким то придуманным своим персональным нормам, а не тому в чем разница между казалось бы одними и теми же данными, и тому что нужно знать разницу между скоростью выборок и работой с тем или иным форматом.

[MaHarder 20]

1 час назад, celsoft сказал:

А DLE как известно готовый коробочный продукт, а не фрейворк

Причём тут фреймворк до 3. нормы базы данных? я вам о Foreign Keys говорю. Я ради наглядности сделал пару связок:

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

 

1 час назад, celsoft сказал:

Поэтому она и не создавала CMS

Ну, вы сами говорите, что не стоит утверждать то, что не знаете. У нас преподователи хорошо получают, больше чем в больших/крупных компаниях. Чем она занималась во время работы на свободном рынке - не вам осуждать. По программе обучения IHK считается, что быстродействие и реакция между таблицами наилучше всего достигается при нормализации единообразных названий начиная со второй нормы. Не мне вас судить, если учесть, что даже в Deutsche Bahn бардак с базой данных, то там и уровень разработки выше. Простите, вы имеете опыт работы в Data Warehouse? Моя училка - имеет. Но, это не имеет значения, я лишь хотел преукрасить ситуацию с базой данных. Не думал, что вы так зациклитесь на ней. Я хотел лишь указать на не систематические названия и структуру.

 

1 час назад, celsoft сказал:

Так создайте свою CMS, потом похвастаетесь, и мы посмотрим на ее производительность.

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

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]];
}

А если поле изменится, то, на данный момент, нужно исправлять это через поиск и замену в базе данных. Очень удобно и производительно. Решать вам.

1 час назад, celsoft сказал:

И это правильно.

тогда, может сразу всё в текстовом формате сохранять? Ведь конвертировать даты можно и при помощи функции convert, date и т.д. в базе данных. Это же сколько сэкономит на производительности?

 

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

 

И всё же, один вопрос остаётся открытым

21 час назад, MaHarder сказал:

В таблице usergroups проверьте поле max_edit_days. Точно однозначный int?

ибо аналогичные ему - имеют 6ти значное число

 

 

 

==========================

 

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

Изменено 11 декабря 2019 пользователем MaHarder

[crafic 32]

50 минут назад, MaHarder сказал:

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

select xf.name, xf.alt_name from xfields xf, post_xfields px where xf.id = px.xfield and news_id = 1

Это уже дополнительный запрос в бд 😃. я б наверно в serialize их.

 Как сделано в dle так и вы подстраивайтесь под него. Нужно удалить новость - смотрите как движок удаляет. Там есть функция вроде deleteNewsById.

 

[MaHarder 20]

57 минут назад, crafic сказал:

Это уже дополнительный запрос в бд 

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

1 час назад, crafic сказал:

я б наверно в serialize их.

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

 

1 час назад, crafic сказал:

deleteNewsById

есть, полезная функция

[celsoft 6 072]

3 часа назад, MaHarder сказал:

Ну, вы сами говорите, что не стоит утверждать то, что не знаете.

Своих конкурентов я знаю. 

 

3 часа назад, MaHarder сказал:

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

select xf.name, xf.alt_name from xfields xf, post_xfields px where xf.id = px.xfield and news_id = 1

Да ладно, а что это у нас вдруг news_id = 1 нарисовался? У нас что доп. поля только в полной новости показываются. А теперь достаньте их на 10 кратких новостях, и в пяти блоках custom, и все это в пределах одной страницы. Я посмотрю у кого решение производительнее, при 500 000 запросах в сутки к примеру. И записей в базе под миллион. Думаете таких сайтов на DLE нет? Так я вас разочарую. Многие решения пришли при анализе работы именно таких сайтов.

 

3 часа назад, MaHarder сказал:

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

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

 

3 часа назад, MaHarder сказал:

тогда, может сразу всё в текстовом формате сохранять? Ведь конвертировать даты можно и при помощи функции convert, date и т.д. в базе данных. Это же сколько сэкономит на производительности?

Ну в вашем же понимании конвертеры за счет воздуха работают, и ресурсов не потребляют.

 

3 часа назад, MaHarder сказал:

Не сомневайтесь, создам. А покажу - будет зависеть от работодателя.

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

 

3 часа назад, MaHarder сказал:

Ведь проще удалить, к примеру, одну новость со всеми логами, комментариями, файлами и т.д. ОДНИМ запросом, нежели n запросами, поскольку таблицы будут связаны друг с другом.

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

 

В 10.12.2019 в 17:21, MaHarder сказал:

Почему не использовать Foreign keys?

На этот вопрос я вам не отвечал, но отвечу. Потому что существенно замедляется скорость записи и обновления. А на крупных сайтах, с большим количеством одновременных посетителей, это критично.

 

3 часа назад, MaHarder сказал:

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

В том то и дело, что вы свою "библию" тянете другим как "идеальную". А правда в том, и что подтверждает мой опыт, что понятия "идеальности" просто не существует. Любой другой программист назовет вашу "идеальную" структуру идиотской, и будет по своему прав, потому как он пишет по другому. Удобство понятие индивидуальное и у каждого свое.

 

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

 

Ваша проблема, что вы забываете самого главного. Писать код нужно не ради кода. И не важно сложный он или простой. А важно что пишите не код а продукт, которым будут пользоваться люди. Писать код нужно ради продукта, а не ради кода. И именно продукт должен работать быстро, качественно и  на благо пользователя, а пользователю глубоко "по барабану" одна строка в коде или десять, но при этом далеко не по барабану, когда ради десяти посетителей нужно брать отдельный сервер, а для тысячи уже кластер (это я просто условные цифры привел, для примера)

 

3 часа назад, MaHarder сказал:

И я понимаю, что для этого нужно будет принудительно обновить базу данных до InnoDB.

Это вообще вызывает улыбку, потому что пришел господин MaHarder и говорит, ну ка быстро выкинули больше 15 000 своих клиентов. Потому что мне на них все равно, и все равно что у них на сервере стоят старые версии MySQL, в которых InnoDB не поддерживает полнотекстовых индексов.  Поэтому DLE автоматически определяет установленное ПО и может работать как на старом ПО, так и на новом используя как MyISAM так и InnoDB. Хостеры крайне консервативны, и редко обновляют работающее ПО. Хотя есть и такие кто использует всегда актуальное. И это не повод выбрасывать нам за борт своих клиентов, и ставить их в положение.

[mr. Freeman 11]

В 11.12.2019 в 21:25, celsoft сказал:

Это вообще вызывает улыбку, потому что пришел господин MaHarder и говорит, ну ка быстро выкинули больше 15 000 своих клиентов. Потому что мне на них все равно, и все равно что у них на сервере стоят старые версии MySQL, в которых InnoDB не поддерживает полнотекстовых индексов.  Поэтому DLE автоматически определяет установленное ПО и может работать как на старом ПО, так и на новом используя как MyISAM так и InnoDB. Хостеры крайне консервативны, и редко обновляют работающее ПО. Хотя есть и такие кто использует всегда актуальное. И это не повод выбрасывать нам за борт своих клиентов, и ставить их в положение.

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

[Captain 623]

34 минуты назад, mr. Freeman сказал:

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

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

[mr. Freeman 11]

18 минут назад, Captain сказал:

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

Мнение флудерастов не особо интересно, больше некуда всунуть свою рефералочку? Аж в каждой теме бред на бреде, более авторитетный флудер чем вы, тут разве что alukardua.

[proba 57]

9 часов назад, mr. Freeman сказал:

более авторитетный флудер чем вы, тут разве что alukardua

кто его уже только не вспоминал. 🤣🤣🤣🤣🤣

[MaHarder 20]

@celsoft

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

 

Если вам так угодна скорость и работоспособность базы данных, то почему же не использовать SQLite? Она идеально подходит вашим требованиям, даже лучше. На вебхосте даже не нужно иметь отдельно базы данных. И взаимодействие будет происходить куда быстрее и эфективнее. То, что ваши 15000 клиентов сидят на MyISAM - ничего страшного, обновят в ходе обновления движка. А те, кто не сидит на актуальных версиях - обновлять не будет и их это ну никак не коснётся. Тем более, что минимальное требование по MySQL значится как 5.5.3. Рано или поздно вам всёравно придётся обновляться. А с версии 5.5.6 InnoDB уже стандартный движок MySQL. Конечно, опыт с хостерами у нас разный, но на моём опыте - пока никто из хостеров не отказывал в апгрейде MySQL, ибо им это не выгодно.

 

Да, у вас в CMS системах больше опыта, чем у меня, поскольку я работаю с ERP-системами.

 

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

[celsoft 6 072]

11 часов назад, MaHarder сказал:

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

Не совсем правильное тестирование. Вам не нужно преобразовать 36 000 записей из одного формата в другой. DLE таких вещей не делает. Преобразования делаются у результатов выборке, а не выборке. В этом суть. Вот смотрите, вам нужно показать 10 популярных записей за месяц. Вам нужно подготовить код для этого и сделать выборку. Если у вас Integer то вы должны расчитать что за месяц, сколько в нем дней, а что за год, вдруг високосный и февраль отличается по количеству дней. Гора кода, по результатом которой вы отправляете нужный Integer на выборку, и выборка будет быстрее чем если был бы datetime, но использовать Integer глупо, из за того что куча расчетов идет до самой выборки чтобы просчитать нужный Integer. Поэтому общая производительность будет выше именно при datetime, ну и проще в разы. А теперь случаи где не нужно выбирать по месяцам, то использовать datetime не выгодно, потому как и выборка по нему медленнее и в памяти он занимает больше место чем Integer. Выгода Integer очевидна. А  varchar используется вообще редко, там где выборки по нему вообще нет, и он только в результах используется, а не в самой выборке. Понимаете суть?

[mr. Freeman 11]

В 17.12.2019 в 02:00, celsoft сказал:

Не совсем правильное тестирование. Вам не нужно преобразовать 36 000 записей из одного формата в другой. DLE таких вещей не делает. Преобразования делаются у результатов выборке, а не выборке. В этом суть. Вот смотрите, вам нужно показать 10 популярных записей за месяц. Вам нужно подготовить код для этого и сделать выборку. Если у вас Integer то вы должны расчитать что за месяц, сколько в нем дней, а что за год, вдруг високосный и февраль отличается по количеству дней. Гора кода, по результатом которой вы отправляете нужный Integer на выборку, и выборка будет быстрее чем если был бы datetime, но использовать Integer глупо, из за того что куча расчетов идет до самой выборки чтобы просчитать нужный Integer. Поэтому общая производительность будет выше именно при datetime, ну и проще в разы. А теперь случаи где не нужно выбирать по месяцам, то использовать datetime не выгодно, потому как и выборка по нему медленнее и в памяти он занимает больше место чем Integer. Выгода Integer очевидна. А  varchar используется вообще редко, там где выборки по нему вообще нет, и он только в результах используется, а не в самой выборке. Понимаете суть?

Вы не берёте в расчёт авторов модулей, которые могут добавлять поиск по таким колонкам.

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

[celsoft 6 072]

3 часа назад, mr. Freeman сказал:

Вы не берёте в расчёт авторов модулей, которые могут добавлять поиск по таким колонкам.

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

3 часа назад, mr. Freeman сказал:

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

Как раз таки DLE и заточен под обилие данных. И если сделать как говорите вы, нагрузка на БД только увеличиться

[mr. Freeman 11]

6 часов назад, celsoft сказал:

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

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

Приведу пример с чем столкнулся в последний раз из самого досадного.
Вы в функции show_attach в угоду своему быстродействию, сделали так что легко и просто нельзя добавить вывод полного пути к файлу, если для кода вставки задано имя файла.
Хоть иногда думайте о таких вещах когда в угоду быстродействия заставляете сторонних разработчиков переписывать целые функции из-за кода в 20 символов и одной строчкой.

6 часов назад, celsoft сказал:

Как раз таки DLE и заточен под обилие данных. И если сделать как говорите вы, нагрузка на БД только увеличиться

Вы выше только что и подтвердили, что нагрузка вырастет на базу, но уменьшится PHP код (~15 строк кода не такое уж и гора что бы ленится его написать), хотя при росте объёмов данных, как раз таки база и страдать будет.
В своё время забивал базу DLE синтетикой и тестировал (под 100 миллионов новостей), и проблемы были уже просто в скорости выборки из базы (особенно с тогдашним одним JOIN, сейчас их уже целых два), нежели в обработке всего этого на PHP. Одна тема у Сандера как бы намекает, что крупные проекты исправляют многие такие "оптимизации" под свои реалии, а то им от этого плохеет.

[celsoft 6 072]

18 часов назад, mr. Freeman сказал:

Вы выше только что и подтвердили, что нагрузка вырастет на базу, но уменьшится PHP код (~15 строк кода не такое уж и гора что бы ленится его написать), хотя при росте объёмов данных, как раз таки база и страдать будет.

Вы не внимательно читаете, я писал что по сути не будет баланса. Снизив одно, вы нагрузите CPU другим, и не добьетесь в результате ничего. Дело не в количестве кода, как количестве. Или ваш код за счет воздуха работать будет?

 

18 часов назад, mr. Freeman сказал:

В своё время забивал базу DLE синтетикой и тестировал (под 100 миллионов новостей), и проблемы были уже просто в скорости выборки из базы (особенно с тогдашним одним JOIN, сейчас их уже целых два), нежели в обработке всего этого на PHP.

Вот и напишите как с сохранением всех текущих функций ее снизить. Уже столько сообщений в этой теме, и ни одно ваше сообщение не позволяет сделать эффективней. Ваше сообщения только о том, почему разные типы, это же не просто и удобно поддерживать. А не про то как сделать нагрузку ниже и эффективней. Если есть что предложить как снизить нагрузку, предлагайте, я это вам еще выше сказал, а все остальное про ваше личное удобство и потому что вас так учили, вот это уже лишнее.

 

18 часов назад, mr. Freeman сказал:

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

Мы добавляем все что нам нужно легко и быстро, без каких либо проблем. Почему когда мы разрабатываем новый функционал, можем это сделать а вы нет? Это уже вопрос личных знаний, а не вопрос удобен код или нет. У каждого свое удобство. А код мы пишем не ради кода, а ради функционала.

18 часов назад, mr. Freeman сказал:

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

Любой крупный проект всегда затачивает все именно под себя, потому как универсальное решение "для всех" далеко не всегда идеально для точечной задачи. Поэтому коробочная CMS практически никогда не используется крупных проектах. Думаете яндекс на битриксе построен или на вордпрессе? ))))) Нет конечно. Крупный проект уже всегда пишется под проект, там код уже четко под его данные без каких либо настроек, коих в том же DLE уже несколько сотен. Потому как DLE коробочная CMS для всех, а не под проект.

[mr. Freeman 11]

1 час назад, celsoft сказал:

Вы не внимательно читаете, я писал что по сути не будет баланса. Снизив одно, вы нагрузите CPU другим, и не добьетесь в результате ничего. Дело не в количестве кода, как количестве. Или ваш код за счет воздуха работать будет?

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

1 час назад, celsoft сказал:

Вот и напишите как с сохранением всех текущих функций ее снизить. Уже столько сообщений в этой теме, и ни одно ваше сообщение не позволяет сделать эффективней.

У меня в этой теме вообще два сообщения всего, по этому не понимаю ваших претензий в этом плане.

1 час назад, celsoft сказал:

Ваше сообщения только о том, почему разные типы, это же не просто и удобно поддерживать. А не про то как сделать нагрузку ниже и эффективней. Если есть что предложить как снизить нагрузку, предлагайте, я это вам еще выше сказал, а все остальное про ваше личное удобство и потому что вас так учили, вот это уже лишнее.

 

В 17.12.2019 в 02:00, celsoft сказал:

Вот смотрите, вам нужно показать 10 популярных записей за месяц. Вам нужно подготовить код для этого и сделать выборку. Если у вас Integer то вы должны расчитать что за месяц, сколько в нем дней, а что за год, вдруг високосный и февраль отличается по количеству дней. Гора кода, по результатом которой вы отправляете нужный Integer на выборку, и выборка будет быстрее чем если был бы datetime, но использовать Integer глупо, из за того что куча расчетов идет до самой выборки чтобы просчитать нужный Integer. Поэтому общая производительность будет выше именно при datetime, ну и проще в разы.

Судя по тестам, int быстрее и проще выбирается. Вы сами это выше подтверждаете, но говорите что вычисления диапазона int на PHP это такая очень затратная операция.

1 час назад, celsoft сказал:

Мы добавляем все что нам нужно легко и быстро, без каких либо проблем. Почему когда мы разрабатываем новый функционал, можем это сделать а вы нет? Это уже вопрос личных знаний, а не вопрос удобен код или нет. У каждого свое удобство. А код мы пишем не ради кода, а ради функционала.

Ну конечно просто, потому что вы переписываете функцию.
Вы точно проверили то что можно одной строчкой добавить то что я описал, или всё таки не утверждаете того что для этого нужно переписать функцию?

1 час назад, celsoft сказал:

Любой крупный проект всегда затачивает все именно под себя, потому как универсальное решение "для всех" далеко не всегда идеально для точечной задачи. Поэтому коробочная CMS практически никогда не используется крупных проектах. Думаете яндекс на битриксе построен или на вордпрессе? ))))) Нет конечно. Крупный проект уже всегда пишется под проект, там код уже четко под его данные без каких либо настроек, коих в том же DLE уже несколько сотен. Потому как DLE коробочная CMS для всех, а не под проект.

Эти простые истины всем почти известны, но это не отменяет того что в DLE полно мест где есть что подкрутить.

[celsoft 6 072]

7 часов назад, mr. Freeman сказал:

Что то мне подсказывает, что простые арифметические вычисления в PHP куда меньше нагрузят тот же условный сервер, нежели более сложная выборка из базы

Заблуждение. Это не универсально. Все может быть по разному в зависимости от ситуации.

 

7 часов назад, mr. Freeman сказал:

У меня в этой теме вообще два сообщения всего, по этому не понимаю ваших претензий в этом плане.

В таком случае, прежде чем писать, прочитайте внимательно всю тему и главное в чем ее суть, и только потом вмешивайтесь и пишите. Мы обсуждаем одно, а вы вклиниваетесь со всем другим. Я же продолжаю писать исключительно по сути темы.

 

7 часов назад, mr. Freeman сказал:

Судя по тестам, int быстрее и проще выбирается. Вы сами это выше подтверждаете, но говорите что вычисления диапазона int на PHP это такая очень затратная операция.

Опять таки вырвано из контента, более того основано лишь на теоретических предположениях. Я не писал "очень затратная операция", я написал, что не имеет практического смысла потому как будет нарушен баланс по другой нагрузке. Нужно понимать как все работает. Например, вычисления на PHP будут при каждом запросе, а при выборке вычислений каждый раз MySQL делать не будет, и выборок по сути делать не будет, он сбросит сразу результаты из своей памяти, т.к. это уже делал. Например миллион обращений в секунду, PHP сделает миллион раз одни и те же расчеты, MySQL сделает выборку и расчеты один раз, а остальные 999 999 раз сбросит сразу готовый результат.

 

7 часов назад, mr. Freeman сказал:

Вы точно проверили то что можно одной строчкой добавить то что я описал, или всё таки не утверждаете того что для этого нужно переписать функцию?

Я могу хоть весь DLE написать одной строчкой. Если у вас проблема с написанием кода, это не равно что проблема в коде DLE.

 

7 часов назад, mr. Freeman сказал:

но это не отменяет того что в DLE полно мест где есть что подкрутить.

Не отменяет, и DLE как раз имеет линейный код, а линейный это самый простой код для понимания. Т.е. имеет самый низкий порог вхождения. Что порой конечно и добавляет проблем из за низкого порога входа, приходится часто писать о самых простых и прописных истинах многократно.