Помогу молодым украинскам проектам (.NET)

Помогу спроектировать и реализовать бекенд в Вашем проекте
(бесплатно или за символическую часть стартапа в зависимости от обьема работ) при условии использования моей СУБД.

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

Для чего это мне
Получить дополнительно несколько новых клиентов и показать возможности базы.

О базе данных
Документоориентированная база с ОРМ, транзакциями и поддержкой ACID
Ближайший родственник — Монго

Есть ли опыт внедрения
Есть, на нескольких тестовых проектах.
Включая проект где около 30 «таблиц» + 50 «процедур»

Что за проект
Здесь
github.com/Bazist/DniproServer.WIN

Здесь пример бекенда и синтаксиса
github.com/...ben/Booben/Helpers/DAL.cs

Здесь пример документации
github.com/Bazist/Books

Когда предложение уже будет не актуально
Когда наберется 2-3 проекта

Подробнее можно написать мне здесь или в этой теме
support@pikosec.com

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

А как embedded database под UWP (как замена SQLite) может быть?

Да, может. База по размеру сама по себе легковесная, поскольку не использует сторонних компонент. Единственное могут быть вопросы по потребляемой памяти на больших обьемах данных, поэтому может понадобится дополнительный тюнинг в зависимости от модели самого устройства и размеров хранимых данных.

Очень интересный проект! А будет какой-то блог, или публикации (например на Хабре) где можно было бы отслеживать историю развития проекта? Возможно в будущем применил бы где-то в одном из своих проектов!

Спасибо за отзыв !
Для хабра планируется цикл статей в ближайшее время.
Обещал правда их написать раньше (мне даже прислали авансом приглашение на хабр),
но поскольку было ряд доработок и улучшений, решил повременить до их окончания.
Сейчас же я вижу, что база вошла в достаточно стабильную версию. При написании тестового проекта уже очень мало обращаюсь к отладке самой базы. Сам же синтаксис позволяет написать 3-5 «хранимок» вподряд и не сделать ниодной ошибки. Поэтому думаю время выкатываться на хабр :)

А зачем bin и obj, закомитили?

Гит по дефолту их комитит.
Нужно вручную гитигнор править.
Гдето я поправил, гдето нет.

Оце теж не треба комітити .vs/DniproDB/v14.
Є стандартний .gitignore для VS github.com/...er/VisualStudio.gitignore

Это же ДнипрпоДБ

Шукаю таку людину як ви, тільки зі знанням Node.JS, PostgreSQL, Redis, RabbitMQ. Для глобального стартапу, звісно.

Уберите со своей связки буржуйские

PostgreSQL, Redis
и тогда можно будет разговаривать.

Вашу СУБД в production?

Да. Не понравится, откажетесь — перепишите.=)
Но думаю проблем не будет.

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

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

PostgreSQL
почти нашенский - exUSSR,

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

Post Ingres - детище Стоунбрейкера и его студентов в бородатых годах.

Не наш он. Хотя в раше его внесли в госреестр как рекомендованое ПО
для использования в гос структурах. Но туда много чего внесли включая Линтер.

твоя бесплатная помощь очень дорого обойдется коммерческому проекту из-за этой лютой базы и ее лицензии => годится только для некоммерческих проектов или для прототипов

Подвохов никаких нет.
Лицензия, дело решаемое.

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

Риск компенсирую тем, что бекенд соберу бесплатно. Нанять разработчика, который соберет например бекенд для проекта на 50+ таблиц и 100+ процедур ( как мой пример из гита) на том же Оракл/Мускуль, это очень дорого. Код будет с душком и временные сроки тоже растянутся.
Я ищу клиента который готов рискнуть и поучаствовать в Proof of Concept.
Сам же берусь за работу, потому что уже собирал проекты и уверен в базе данных.

Если бы к новому никто не прикасался, сидели бы сейчас повсеместно на какомто ФоксПро и Мумпс.

Нанять разработчика, который соберет например бекенд для проекта на 50+ таблиц и 100+ процедур ( как мой пример из гита) на том же Оракл/Мускуль, это очень дорого.
для коммерческого проекта нанять разработчика дорого? что-то тут не так
Риск компенсирую тем, что бекенд соберу бесплатно
это оправданно только когда проект в долгосрочной перспективе будет 100 долларов в месяц приносить, только что это за коммерческий проект такой?)

Пускай напишет тот проект, который хочет получить реальное конкурентное приимущество на рынке.

Таким приимуществом я считаю несколько показателй.
1. Код бекенда будет чище и проще
2. Работать он будет значительно быстрее чем аналогичные решения. Разница вполне может составлять в 50 раз и больше. Бенчмарков приводил не мало.
3. Получит такой бекенд бесплатно. Деньги пускай пустят на рекламу.

Если же ктото хочет чтобы «бульо як увсих», то пускай пишет. Таких проектов на рынке, как их качество и цены, вроде как всем известны.

та не преимущества это

1. Код бекенда будет чище и проще
чище и проще чего? плейн скл? не проще и не чище он, он громоздкий с кучей скобок, вот это { like } } } } } } } в экран вложенностей развернется у тех кто не пишет код в одну строчку, а таких я надеюсь большинство
2. Работать он будет значительно быстрее чем аналогичные решения. Разница вполне может составлять в 50 раз и больше. Бенчмарков приводил не мало.
а на каком объеме оно захлебнется? и может ли оно все то что настоящие бд?
3. Получит такой бекенд бесплатно. Деньги пускай пустят на рекламу.
работа одного программиста незначительная трата
чище и проще чего? плейн скл? не проще и не чище он, он громоздкий с кучей скобок, вот это { like } } } } } } } в экран вложенностей развернется у тех кто не пишет код в одну строчку, а таких я надеюсь большинство

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

К томуже, там есть такая сущность Like. Лайкнуть в этой системе можно пользователя, созданную им библиотеку, лайкнуть поискового робота, или комментарий который оставили или для библиотеки или для поискового робота. А теперь подумайте над развязками в реляционной системе и уровнем их сложности хотябы просто для таблицы Like

а на каком объеме оно захлебнется? и может ли оно все то что настоящие бд?

Горизонтальное масштабирование никто не отменял для документоориентированых баз данных.

хм и как тогда при

Горизонтальное масштабирование
реалиовано
транзакциями и поддержкой ACID

?
PS. насчет объема данных на каких объемах тестировал ?

хм и как тогда при
Горизонтальное масштабирование
реалиовано
транзакциями и поддержкой ACID

Они друг другу не противоречат.

PS. насчет объема данных на каких объемах тестировал ?

Стандартный бенчмарк, который вызывается если в консоле набрать db.SelfTest() запускает около 10 миллионов запросов insert\update\select которые за теже 8-10 сек и отрабатывают на обычной машине.

Ну так подойдите к своему сыродателю и скажите ему. Что тебе еще стоит мне на 50% количество сыров повысить. Подумаешь,

работа одного программиста незначительная трата
Код бекенда будет чище и проще
Ой не зарекайтесь...

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

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

тразакции, скорость
К этому вопросов нету.
норм синтаксис
А вот это неверно. Не знаю, может в .NET все настолько плохо (могу судить только по JS и Ruby), но такой синтаксис:
Comment[] comments = DB.GetWhere(new Article { Comments = { new Comment { Author = «mobile mobile» }}})
.Select<comment>();
не сильно норм. Тут сильно не хватает «сахара». Но если сравнивать, например, с raw sql, то это получше.

Так давайте пример на JS и Ruby данной выборки. Попробуем сравнить, может чтото позаимствуем.

Да, без проблем.
Оба языка предоставляют библиотеки с синтаксисом схожим с:

Article.joins(:comments).where(comments: {author: ’mobile mobile’})

Т.е. в рельсах — это ActiveRecord. В яваскрипте — Sequelize, node-orm, mongoose (для монги, т.е. джойнов нету, но синтаксис годный, имхо).

Я понимаю, что это немного не относится к драйверу DB, но если говорить про синтаксис, планируете ли написать ORM под свою базу. Ведь, добавив модели и аналоги belongs_to, has_one, has_many (из ActiveRecord, например), можно было бы сделать код более привлекательным, за счет плюшек типа Article.comments.

С другой стороны, что мне не понравилось — это жирная конструкция. Все эти `new Comment` и аналогичные мозолят глаз.

В общем, все аналогично, но много текста можно писать покороче :)

P.S.: судя по поставленной задаче, join тут не нужен :) т.ч. обойдемся:

# ActiveRecord
Comment.where(author: ’mobile mobile’)

// Mongoose
Comment.find({author: ’mobile mobile’})

// Mongo
db.comments.find({author: ’mobile mobile’})

P.P.S.: после предыдущих кусков кода понял, что мое недовольство действительно обусловлено количеством символов, необходимых для запроса :)

Ну давайте попробуем разобрать

Код Монго

// Mongo
db.comments.find({author: ’mobile mobile’})

Наш код


getWhere("{Comments:[{author: ’mobile mobile’}]}")

Усложним условие. Найти все комменты пользователя mobile mobile на активных страницах


getWhere("{IsActive:1, Comments:[{author: ’mobile mobile’}]}")

Как видим, у нас используется просто шаблон. Из-за этого минимум модификации если нужно усложнить условием.
Мы задаем ту часть которая должна совпасть с документом.

Монго же запрос, прийдется переписать.

Рельсовый код :P

.where(isActive: 1, comments: {author: ’mobile mobile’})

По поводу монги — да, но она не катит, т.к. джойнов не имеет.

Но есть другой вопрос. В предыдущем примере использовались объекты (но через `new`), в данном — строка, содержащая обычный объект. А есть ли возможность просто использовать «пустые» объекты, т.е.:

getWhere({IsActive:1, Comments:[{author: ’mobile mobile’}]})

Задаю вопрос, потому что не знаю, как это устроено в .NET.

Задаю вопрос, потому что не знаю, как это устроено в .NET.

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

GetWhere("{FirstName:'John',LastName:'Smith'}");

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

Шарп нам позволяет делать синтаксический сахар.
Например у меня есть класс

class User 
{
public string FirstName;
public string LastName;
}

И я хочу написать тотже запрос.
Я пишу тогда вот так

GetWhere(new User{FirstName = "John", LastName = "Smith"});

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

{FirstName:'John',LastName:'Smith'} 

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

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

А можно пример более комплексного запроса, может действительно смогу что-то предложить дельного? :)

Можно. Вот симфония синтаксиса

//notify subscribers
            DB.GetWhere(new User { Login = login, Libraries = { new Library { Name = libName, Subscribers = { new Subscriber { IsActive = true } } } } })
                .Join(new User { Libraries = { new Library { Subscribers = { new Subscriber { Login = "" } } } } },
                      new User { Login = "" })
                .Insert(new User { Events = { ev } },
                        Change.CreateOne(ev, ChangeEnum.Add),
                        JoinedEnum.SecondTable);

Не смотрите на количество скобочек.
Запрос делает следующее. Найти пользователя по логину, у него в коллекции Libraries найти библиотеку по имени. У этой библиотеки есть коллекция Subscribers которая содержит список логинов подписчиков. Пробежаться по этой коллекции (джоин) и добавить каждому подписчику в коллекцию Events новое событие Event обьект ev.

Весь этот массовый инсерт, можно сделать за один запрос.
Как это сделать также лаконично в один запрос через Монго или SQL даже не представляю. Между тем запрос вполне себе рабочий, обычное оповещение пользователей о событии в системе над какойто сущностью.

Во, спасибо :) Вот это уже гораздо интереснее однострочных запросов :)

Мда... Повтыкав на этот запрос, понял, что понятия не имею, как это сделать (не двумя запросами) на mongo/sql...

поработай в каком нибудь BI, там быстро научишься писать SQL запросы любой сложности

Можешь привести пример аналогичного запроса на SQL?

Такой запрос можно написать через трехэтажный запрос INSERT INTO SELECT но при единственном условии, если обьект Event не иерархический и равен вставке одной строки в таблицу Event. А он вообщето иерархический, потому портит всю реляционную малину для MS SQL. Уже нужен не один запрос, а целый скрипт.

Любой запрос можно написать одним DML стейтментом. Вопрос в другом — целеообразно ли это.

целеообразно ли это.

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

db.AddDoc(obj)

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

Как можно писать запросы без схемы ?!

В комментарии выше написано достаточно информации для примерного понимания схемы необходимой для этого запроса.

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

а где хостить ее , как ставить и т.д. ?

Можно не ставить. Просто запустить консоль, подобно Монге. Прямо в консоле уже можно писать и выполнять запросы, админить сервер. Сервер откроет порт 4477 и будет готов принимать внешние запросы.

Дальше добавляем драйвер к себе в солюшин DniproClient NET и мы готовы писать запросы

DniproDB DB = new DniproDB("127.0.0.1", 4477);

Например, если бы Доу был бы на Днипре, то все комментарии пользователя mobile mobile можно было бы найти както так

Comment[] comments = DB.GetWhere(new Article { Comments = { new Comment { Author = "mobile mobile" }}})
.Select<Comment>();

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

бекэнд (рест апи) на пхп

Если заменить на

бекэнд (рест апи) на дот нет

Но тут вопрос.

диджитал океан

Даст какоето Вин пространство чтобы запустить дотнет приложение ?

там виртуальная машина с линуксом планировалась, не уверен есть ли там инстансы с виндовсом.

Можно попробовать запустить на mono, но вариант лучше — хостить все в Azure. Там есть и Linux и Windows.

Получить простой чистый и понятный код
красиво написано :)
а еще понравился класс MainController с Index() :)
Ps. придираться к коду не буду — надеюсь очевидные моменты поправите перед сотрудничеством с новыми проектами

MainController не имеет никакого отношения к бекенд части. Это фронт часть, ее каждый пишет кто как хочет. Тоесть в стартовом топике речь только о Data Access Layer акумулирующую в себе логику с базой данных и запросами к базе данных. В выхлопе у вас будет готовая обьектная модель, на которую можно натягивать любую фронт логику.

Контроллеры после этого получаются простыми как табуретка.
Например процесс регистрации через визард в 2 этапа
github.com/...RegistrationController.cs

Как видим из логики к базе данных тут вызовы DAL методов AddUser, UpdateUser и всё. Все максимально просто и логично.

понял, искренне желаю Вам удачи ! :)

Ну что, господа сыроеды.
Составим нашу конкуренцию Монге-Понге,
или все будет как обычно по-хуторянски «используем чужое даже если есть свое лучше»,
Неужели название Днипро выбрано зря из-за патриотизма.
Раз такое дело, наверное стоит переименовать и не акцентировать внимание на корнях
продуктового стартапа :(

Я бы переименовал, такой сильный акцент на городе как-то не очень. Хотя у Cisco прокатило же.

Ну тут на речке больше акцент (я в другом городе), но да, наверное буду переименовывать.

Там есть Линк запросы по концепции, а не с привязкой к дот нет фреймворку.
За это отвечает DniproQuery интерфейс.

Его плюс, он един и его можно использовать из С++, Джава, Дот Нет, Пхп, командной строки, да из любого языка вообщемто.

Второй его плюс, он однозначно транслируется в джисон, что открывает хорошие возможности по профилированию, импорту/экспорту данных и др. возможностям.

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

Четвертый плюс. Он таки работает быстрее.

Не существует драйверов подключения или СУБД, которые поддерживают LINQ. Существуют .NET клиенты , которые в качестве фичи могут иметь ограниченную поддержку трансляции примитивных Linq Expressions в нативные Queries. Такой компонент можно написать к любой базе, которая имеет встроенный язык выражений или просто public api, какой-то особой поддержки на уровне драйвера тут не нужно, это всего лишь слой абстракции на стороне клиента.

По-моему со всем согласны. Драйвером они называют свой клиент и все фичи, которые входят в состав библиотеки-клиента. А не компонент подключения.
Например каждый может взять ADO.NET и написать такую поддержку LINQ как ему захочется в свое приложении — это же не значит что у ADO.NET есть какая-то особая поддержка LINQ, эти компоненты ничего не знают о LINQ поскольку это от начала до конца клиентская фича, такая же как например и обычный метод в классе репозитория, который форматирует SQL из входящих параметров.

Если СУБД быстрая, масштабируемая и отказоустойчевая — иными словом хороша собой и подходит под потребности, отсутствие LINQ клиента это последнее что должно волновать человека при выборе в пользу такого решения перед конкурентами.

Подписаться на комментарии